Proyecto de InuetigacioQ I y

Transcripción

1 Proyecto de InuetigacioQ I y C.. \ /&eo, DJ,, Dicimbre de _UIL._"

2 I N D I C E O.- Modelo de Desarrollo con base a Objeto 1.- Panorama General del Análisis Orientado a Objeto 2.- Conceptos Sobre Modelado de Información 3.- Ciclo de Vida de los Objetos. 1

3 Capitulo 0.

4 MODELO DE DESARROLLO CON BASE A OBJETO Los métodos orientados a objetos pueden crear beneficios en el análisis y diseño, asi como en la codificación. El analisis, el diseño y la programaoión de los requerimientos orientados a objeto son actividades distintas. El analisis de los requerimientos debe ser primero si vamos a entender el problema. El diseno, est6 orientado a objeto o no, e610 se puede hacer despuérs de haber entendido el problema. La programación orientada a objeto está dirigida al lenguaje, implementación y asuntos del medio de la programación. La programación orientada a objeto se puede hacer sin el diseño orientado a objeto o sin.ningún diseño. El diseño orientado a objeto es independiente; una vez creado un diseño orientado a objeto se puede programar en algún lenguaje orientado a objeto, o bien, se pueden simular los objetos en lenguajes tradicionales. Para llegar de una solución orientada a objeto en un problema debemos decidir cuales deben ser los objetos. Con problemas muy pequeños, la selección de objetos puede ser trivial, es deoir, podemos identifioar los objetos mediante la inspección. Para problemas grandes y complejos, la identificación "mediante la inspección" raramente funciona. Es cierto que algunos objetos corresponderán a entidades reconocibles por el usuario en el dominio del problema. Sin embargo, no todas las entidades del usuario son obvias nise pueden descubrir por intuición. También, las entidades del usuario no son las únicas fuentes de objetos. Desde el punto de vista de un diseño o programa orientado a objeto, un objeto es una información privada junto con las operaciones en esa información. Para propósitos de diseño un objeto se caracteriza completamente por sus operaciones. Por ejemplo, no importa si un objeto facturado tiene una partida de información local (sugerencia variable, cualidad, atributo) manteniendo el total facturado o el total se calcula a partir de las partidas individuales en la factura. El total no necesita ser una cualidad almacenada del objeto. Sólo necesitamos saber si cualquier. operación provooa el total facturado al ser invocado. Por lo tanto, cualquier metodologia para el diseño orientado a objeto debe corresponder en si intensamente con la - identificación y especificación de lae; operaciones de los objetos. Desarrollo Basado en el Modelo El primer paso al solucionar el problema es asegurarse de que entiende ouál es el problema. En otro8 oampos, los ingenieros utilizan modelos de sus problemas y soluoiones

5 para entenderlas mejor y ayudar en la comunicaci6n oon los clientes. Varios ingenieros en sistemas utilizan modelos de sus soluciones, pero pocos modelan expllcitamente el problema. Para desarrollar una soluci6n orientada a objeto, primero creamos un modelo en el dominio del problema de lo que entendemos que es el problema. Esto se puede hacer al construir un modelo un análisis de requerimientos orientado a objeto. La estrategia y el modelo descritos proporcionan aqui la información necesaria para decidir sobre los objetos y sus operaciones. Análisis de Requerimientos El término "análisis de requerimiento orientado a objeto" es de alguna forma superfluo, ya que es dificil ver c6mo hacer análisis de requerimientos apropiados sin concentrarse en los objetos bajo el punto de vista del usuario con respecto al problema. Cuando digo que quiero hacer un análisis de requerimiento orientado a objeto, me refiero a que me quiero concentrar en los objetos. Quiero mejorar un sistema ouya solución consiste en cierta forma en o está organizada alrededor de los objetos. En lugar de usar un grupo nuevo y completo de herramientas de modelaje y técnicas asociadas inventadas sólo para representar el problema desde una perspectiva orientada a objeto, es mejor preguntar si oualesguiera de los modelos actuales están lo suficientemente orientadas a objeto. Investigué si una forma más extensa de análisis estructurado podria proporcionar las herramientas neoesarias para los requerimientos del modelaje. La primera reacción a esta pregunta por parte de los familiarizados con el tradicional análisis estructurado fue que no funoionaria porque "el análisis estructurado es una descomposición funcional de un sistema". Este punto de vista del análisis estructural es mucho más limitado. Surge porque a menudo una especificación estructurada parece constar arrolladoramente de simbolos representando procesos (funciones). Es fáoil olvidar que estos procesos aparecen en los diagramas de flujo de datos. El énfasis del diagrama de flujo de datos está (y siempre ha..estado, como lo idearon sus originadores) en la información. Las flechas en un diagrama de flujo de datos muestran el flujo de información hacia y de: entidades fuera del - sistema, almacenes de datos sobre entidades en el sistema y simbolos que representan transformaciones de la~infornaci4n. Esos trabajadores piensan en los diagramas de flujo de datos como una forma de representar la descomposición de las funciones si no interfieren con nuestra forma de usarlos correctamente para representar la transformación y el movimiento de datos sobre entidades. Asi, regreso al intento - 2 -

6 de los originadores enfocando los almacenes de datos y 'entidades del mundo real más que a ~ R S funciones a ser realizadas. u - Para los problemas de tiempo real o aquellos con un componente de control significativo en sus respuestas a casos, las Estrataas Rara la EsDeoifioaci6n dm1 sk&madk -DO Real. de D.J. Hatley y I.A. Pirbhai brinda una mayor coherencia necesaria para un control de modelaje por via de un modelo de control y máquinas de eetado.limitado. En particular, uso sus especificaciones de control en la forma de los diagramas de estado de transición. Otra parte esencial de nuestro modelo es el uso de diagramas de relación de entidad para modelar las partes de una entidad compleja y las relaciones entre las entidades en.el mundo del usuario y la solución. Los idiagramas de relación de entidad proporcionan una excelente herramienta para la comunicación entre el dominio y los especialistas en computación. Al permitirnos describir simple y claramente las entidades y sus relaciones, nos ayudan a localizar objetos candidatos. Diseño Orientado a Objeto Un diseño orientado a objeto es el que cada uno de los m6dulos principales corresponde a una entidad, ya sea en el mundo del usuario o en un mejoramiento de una solución al problema del usuario. El siguiente paso en mi estrategia para un diseño orientado a objeto es construir una lista parcial de objetos candidatos, llamados asi porque reconocemos que se requerirá de alguna repetioión para llegar a su definición final. Del modelo derivamos la mayoria de los objetos candidatos. Refinamos los objetos añadiendo objetos y partiendo o combinando objetos existentes. Tambih refinamos las operaciones definidas para cada objeto. Este paso ayuda a crear más objetos reciclables. Una meta importante es localizar oportunidades para definir operaciones de nivel msls elevado para los objetos existentes. El reoonocimiento y el mejoramiento de las operaciones de nivel más elevado provocan que el diseño del resto del sistema sea más simple.. Fuentes de los Objetos Un sistema de aontrol de cruce de un automóvil ilustra nuestra propuesta. (Este ejemplo ahora clásioo es tan - pequeño que pudimos haber llegado a la mayoria de los objetos por inspiración). La primera fuente de objetos es el grupo de terminadores en el diagrama de contexto (Dibujo 1). El nombre de oada terminador se incluirá en la lista de objetos candidatos. Es probable que el usuario considere a los terminadores entidades y nosostros necesitamos realizar operaciones en - 3 -

7 / Rcsurnc / I I,* Brake-Pushed I. / 1 flgure 2 ' Set cruise control status \ *,.. I 5.,

8 ellos. Los objetos candidatos que ponemos en la lista como 'resultado del examen del diagrama de oontexto son loa siguientes seis terminadores: volante, máquina, válvula de estrangulación, palanca de control del conductor, pedal del freno y el pedal del acelerador. Una rica fuente de objetos en la mayoria de los problemas es la recopilación de los almacenes de datos en el grupo de los diagramas de flujo de datos. Dibujamos un fragmento del diagrama de flujo de datos para cada estimulo al cual debe responder el sistema. Cada fragmento consiste de un proceso junto con el flujo de estimulo (información o control), el (los) - flujo(s> de respuesta correspondiente y cualesquier almacenes de datos necesarios para crear la respuesta. De estos diagramas de flujo de datos podemos añadir objetos candidatos llamados EstatilsCC. y V_elocidad Actual. Dos diagramas de flujo de datos adicionales para el nivel más bajo de la de C~IMU&Q Y Control de Velañadirán dos objetos candidatos más, la YelDcidad Deseada Y el mteo de P m del V W. Algunos de los flujos de datos se pueden convertir en objetos candidatos. Cualquier estimulo (ya sean señales de tiempo o los flujos de datos para los terminadores) o respuesta (flujo de datos a los terminadores) cuya estructura de datos es suficientemente compleja se debe incluir como objeto candidato. Los estimulos y loa flujos de datos de respuesta engloban las entidades del usuario que cruza el limite del sistema (por ejemplo, un informe o un depósito a una cuenta). La razón de que son probables candidatos es que, en contraste con los flujos de datos internos, frecuentemente tienen una compleja estructura de datos internos y sus operaciones se determinan directamente por medio de la politica del usuario. Dichos objetos producen operaciones más interesantes o de nivel más elevado que los objetos de otros flujos de datos. Ninguno de los flujos de datos en este ejemplo particular tienen ninguna complejidad interna, asi que ninguno crea objetos candidatos. Especificación de un Objeto c La definición de un objeto comienza con un nombre adecuado. También es útil indicar si el objeto se derivó de un terninador, un almacén de datos o de flujo de datos. Recuerde que, un objeto se caracteriza completamente por sus operaciones. En la terminologia de programación. esto significa que no tenemos ningún interés en ninguna variable de caso posible en esta etapa, sólo en el grupo de mensajes o invocaciones de operación a los que puede responder el objeto. Asi, la parte interesante y valorable de un objeto es la especificaciones de sus operaciones. Estas - 4 -

9 especificaciones incluyen cualesquier restricciones sobre bualquier estado requerido del objeto en el momento de poner en práctica cada operación. Nombramos cada operaci6n. La mayoría de las operaciones también tienen parámetros. Sin embargo, debemos usar nombres de parámetros convencionales que en una puesta en práotica no son útiles durante la construcción de una lista de candidatos, Si estamos planeando mejorar los objetorp utilizando un lenguaje más distintivo, se necesita alguna anotación que muestre el tipo de cada parámetro en este punto del desarrollo. Eligimos un nombre modelo que es significativo fuera del objeto más que el que indica su uso dentro del objeto. También es útil esta etapa de diseño para mostrar si un parámetro es una entrada, una salida o ambas. Escultura de las Operaoiones Las Operaciones se derivan de lo que llamo escultura a partir de un proceso de bajo nivel (transformaciones de datos) junto con y de los objetos candidatos. Descubrimos qué operaciones se necesitan al examinar los diagramas de flujo de datos y las especificaciones del proceso. Si definimos un objeto de almacén de datos, trazamos cada flujo de datos relacionado con el proceso de más bajo nivel, el cual es la fuente o destino del flujo de datos (Dibujo 2). Al revisar la especificación de cada proceso podemos ver qué operaciones son necesarias en este objeto. En el caso más simple, podemos encontrar sólo las operaciones PONER y OBTENER en el almacén de datos. Por el momento, estas serán las únicas dos operaciones que definimos para este objeto. El resultado final de algunas otras aproximaciones para el diseño orientado a objeto incluirá s610 dichas operaciones simples. Esta metodologia incluye la dirección para identificar las operaciones de nivel más elevado. La estructura de las operaciones es importante pero sencilla. Por ejemplo, al examinar los diagramas de flujo de datos en los Dibujos 3 y 4, podemos observar que sólo los procesos 2.1, 2.2 y 3.2 no tienen ningún contacto con el almacén de datos Act.nal. Para decidir qué operaciones se necesitan realmente para el objeto Velooidad. Actual vemos las especificaciones de eaos tres procesos. Para este pequeño ejemplo, todo lo que tenemos que hacer es abtener la Velocidad Actval y poner un nuevo valor de la Yela&hd A c U. (Debido a las consideraciones de espacio, no se muestran aquf las especificaciones del proueso). Estructuraremos las operaciones para cada uno de los objetos candidatos en turno. Este es sólo el primer paso para llegar a todas las operaciones del objeto. Al realizar este paso en nuestro ejemplo, los objetos y sus operaciones son como se muestran en el Listado 1. Este - 5 -

10 I FIGURE 3. Control speed. n -- ' Speed-Control Throttle Setting Throttle-Setting FIGURE 4. Compute speed Compute Current

11 .. J Accelerator Pedal (Terminator) get( Accelerator-Posítíon Brake Pedal I (Terminator) cutatus get( currentstate) put( currentstate) CurrentSpeed (Data Store) get( Speed 1 put( Speed 1 Driver Control Wand (Terminator) ' accept Resume signal accept Speedlontrol sign2 Engine (Terminator) get( EnginLState ) Throttle (Terilnat or) put( ThrottleSettíng 1

12 ~ es el grupo minimo de operaciones. Sabemos que son necesarias porque las encontramoe en lars espeoifioaciones del proceso. No deberán incluir todas las operaoiones necesarias al completar el diseño detallado; es preferible añadir un número significativo de operaciones a cada objeto durante el paso del refinamiento del objeto. Refinamiento de Objetos y Operaoiones Al examinar diagramas de relación con la entidad relacionados con un objeto, junto con sus operaciones, a menudo encuuentro que el diseño se mejoraria separando un objeto candidato en dos o más objetos. Por ejemplo, la separación de los objetos serviría para simplificar las interfaces para las operaciones de los objetos. Sin la s.eparación, necesitaria un parámetro adicional que especificara, efectivamente, cuál de 1 separados manejaria la operación. Uno de los indicadores principales de u una interface estrecha entre módulos. Con frecuencia, existe un intercambio importante entre el número d para cada objeto y el número de parámetro operación. Los objetos normalmente tienen alguna relac objetos. Por ejemplo, podemos tener objetos de Perso- y con una relación entre ellos. Se puede añadir un objeto para mejorar esta relación entre Parisonas y -. Después de añadir un objeto de relación, cada objeto es más probable que sea reciclable que si la relación se mejora en los dos objetos originales porque al incluir la relación como operaciones en un objeto hace más dificil upjar los objetos por separado. El examen de los dos diagramas de relación de entidad pueden revelar que se deben o más objetos en uno. Debido a las limitaciones de espacio, no he especificaciones de control ni todos los flujos de control en el ejemplo de control de cruce. Una cl ilustra mejor considerando dicho control. objeto encapsula una máquina en estado limitado controlar los demás objetos en el sistema. Se pu como un módulo ejecutivo controlando otros módulos o como un,.objeto de control de estado. Las operaciones para el objeto de control de estado toman la forma de pedir permiso para na determinada acción. n del Grupo En este paso añadimos operaciones a o es neoesario realmente por parte de la esgeoifioación de 108 requerimientos. Hacer esto hace al objeto más reci 6 para futuraet aplicaciones y aumenta el mantenimiento. de. añadir operaciones para t

13 > - 8. 'I operaciones inversos o complementarios. Por ejemplo, si originalmente necesitábamos una operación extendida, quizá.. añadiriamos una operación acortada. Otros pares pueden restwar. divid;ufl/co-. avaruzax/retrw y asi sucesivamente. Suponga que los requerimientos nos llevan a proponer un objeto para un tipo de datos de número complejos. Nuestro análisis nos mostraria, para la aplicación presente, que sólo requerimos operaciones para suma, resta y multiplicación. Incluyendo una operacibn. (ahora no necesaria) para la división hara seguramente a nuestro objeto más reciclable para otras aplicaciones. Operaoiones de Nivel más Elevado Utilizaré el problema de control de cruce para nuestro primer ejemplo de ' operación de nivel más elevado. La operación que inicialmente derivamos del objeto pedal del acelerador fue obtener (Posici.ón del Acelerador). Sin embargo, en la especificación del proceso esto se compara con el valor previo, el cual hemos almacenado. En otras.. palabras, la única razón por la que quisimos obtener la Posicibn del Aoeler- fue ver si había cambiado del valor almacenado previo. La operación que realmente necesitamos fue Caplbio?. Mejorar esta operación de nivel más elevado simplifica de una manera importante el proceso que usa el objeto pedal del acelerador. Con frecuencia podemos identificar una familia completa de oppraciones de nivel más elevado para ~ O E objetos de almacén de datos. Las especificaciones de los procesos que acoesan un almacén de datos determinado puede aparecer al principio para tener sólo las operaciones obtener y m. examen más a fondo de la especificación puede mostrar que Un la mayoria de estas operaciones aparecen en las vueltas. esto nos dice que necesitamos operaciones repetidas de nivel más elevado, que incluyen la colocación necesaria de vueltas variables, revisando las condiciones finales de la operación repetida. Un estudio más detallado de la especificación puede revelar que todo el propósito de la vuelta y sus operaciones incluidas fue calcular el promedio de los valores en un. campo del registro. Asi, las operaciones que realmente queriamos eran tales como 4 Mgxinio y asi sucesivamente. Una buena forma que nos ayudó a. reconocer las operaciones de nivel más elevado en los almacenes de datos fue escribir partes de las especificaciones del proceso en un lenguaje de nivel más elevado como el SQL. Al difinir dichas operaciones de nivel más elevado en varios de los objetos, movimos la mayor parte de la complejidad.del problema a objetos que están, mediante la '6

14 misma estrategia, hechos más reciclables. A menudo, el número de lineas de códigos de fuentes requeridos para más mddulos de aplicación se pueden reducir a más de la mitad como resultado de la definición de dichas operaciones de nivel más elevado en los objetos. Estructura Tradioional A pesar de que la parte más dificil de un diseño orientado a objeto es decidir cuáles deben ser los objetos, queda un número significativo de problemas de diseño. Cómo arreglamos estos objetos con la mejor clase de interconexión? Si cada objeto accesó arbitrariamente a los demás objetos, no podemos comerciar con la complejidad involucrada. En otras palabras, aún enfrentamos el problema de arquitectura del sistema, aún con la mejor elección de objetos. Una posibilidad seria utilizar una estruotura llamada tradicional, jerárquica y modulada. Si una organización ya tiene una mejora significativa en el uso de dichos diseños jerárquicos, esta será la mejor elección. Es conveniente sólo cuando el lenguaje de mejoramiento no es un lenguaje de programación orientado a objeto puro como una Charla, ya que todo en una Charla es un objeto. Sin embargo, la situación es diferente si el lenguaje de mejoramiento es Ada (en donde los objetos se deben imitar). Aún algunos lenguajes orientados a objeto como C++ o Objeto Pascal tienen estructuras tradicionales no de objeto como los procedimientos y las funciones. Debido a que su lenguaje fundamental no se basa estrictamente en el objeto, usando una estructura jerárquica tradicional puede disminuir el riesgo como una organización de software hace la transicibn de una completa metodologia orientada a objeto. Estructura orientada a Objeto Habiendo utilizado una estrategia de diseño orientado a objeto para identificar objetos, es natural preguntar las siguientes preguntas: t Es útil la noción de un objeto para los objetos y otros módulos de organización en unidades más elevadas? * * Nuestro modelo de requerimientos contiene claves para este tipo de conglomeración? * Existe alguna ventaja de tal organización?. Las respuestas positivas a estas preguntas favorecen las nuevas formas de ver la arquitectura del sistema como una jerarquia de objetos. El uso de objetos de nivel más elevado producirá las mismas ventajas que los objetos de nivel más bajo: encapsulaci6n y aislamiento de información y operaoiones relacionadas, planimetria aumentada entre el punto de vista - 8 -

15 del usuario eiobre el sistema y el mejoramiento, potencial reciclabilidad de lots subsistemas y el control aumentado de complejidad. ' I -....I c6mo llegamos a esta jerarquia de objetos? Algunasaproximaciones propuestas no parecen fructiferas. La gente, que siempre ha estado a favor de elevar todo, por supuesto han declarado que un diseño orientado a objeto debe ser elevado y que debemos usar una -clase de refinamiento escalonado de grandes a pequeñw objetos. Las observaciones preliminares de que el tope de la jerarquia elevada debe ser un objeto (consiste de una colección de objetos de nivel más elevado) puede luchar con el principio de que la forma del sistema esté realcionado estrechamente con el problema como lo ve el usuario. A pesar de que se crearán los objetos del sistema interno, cualesquier objetos de nivel más elevado deben ser objetos que el usuario use en forma natural para describir el problema. El usuario necesita, y a menudo lo pide, seguimiento a partir de los requerimientos de la solución. Las propuestas del refinamiento escalonado de los objetos nos dice que debemos crear un objeto simple para todo el sistema? Considere lo que esto significa en relación con un sistema que deberá responder a más de m i l casos diferentes en el mundo real. Cada caso requiere que el sistema responda a uno de m i l estimulos completamente diferentes. Ahora recuerde que un objeto se caracteriza completamente por sus operaciones. Esto implica que el objeto superior tendrá m i l operaciones diferentes. Quiz& el intento es tener algunas operaciones de nivel superior, cada una incluyendo un número de operaciones diferentes, manejadas por el objeto superior. Esto envuelve la definición básica de un objeto como se us6 en la programación y diseño orientados a objeto. Este tipo de refinamiento elevado de objetos no parece ser un modelo 6til. Lo que buscamos son subsitemas que se puedan llamar super objetos, objetos que usan (o contienen) muchos objetos. El diseñador los localiza examinando las grandes abstracciones en el mundo del usuario: Estas grandes abstracciones normalmente corresponden a grupos de entidades. (almacenes de datos y terminadores) que interactúan fuertemente dentro del grupo. Otra forma de encontrar superobjetos es trabajar con uno - de los diagramas de transición de estado de nivel más elevado en nuestro modelo de requerimientos. Los estados en dicho diagrama parecen corresponder a lo que el ueiuario piensa que es funciones de operacibn del sistema. Esta estrategia usa los siguientes pasos para oonstruir una jerarquia de objetos y superobjetos: * Crear un. superobjeto para enoapsular el proceso y los - 9 -

16 objetos que tengan que ver con cada estado en el ' diagrama de transicidn de estado. * Definir operaciones basadas en las entradas,.casos y condiciones que el sistema reconoce en el estado que se está considerando. t Encapsular la memoria del estado requerida en el superobjeto. Dichos superobjetos de estado o de opción son especialmente importantes porque a menudo corresponden a opciones coherentes importantes para el usuario. Aunque es importante en el diseño orientado a objeto, la derivación de nuestros objetos originales es una actividad primaria y es más dificil. Estos objetos incluyen las raíces de las jerarquias de herencia.. Nuestra aproximación reemplaza los métodos de diseño orientado que usan la intuición para determinar los objetos con una estrategia definida para decidir sobre los mejores objetos. En un mayor proyecto industrial, debemos entender exactamente cual es el problema antes de intentar diseñar una solución para él. Así, la preparación del modelo del problema no es trabajo extra; es parte de una estrategia para su solución. La información dada de dicho modelo, un gran número de objetos muy aceptables surge de la aplicación de nuestra estrategia simple. Aún existe una gran oportunidad para la creatividad al hacer finos los objetos y sus especificaciones. Si su organización tiene una gran inversión en otro método de análisis de requerimiento, aún puede utilizar esta estrategia mientras que su método de análisis produce la información que he utilizado para derivar objetos.*

17 . Capitulo 1

18 1. PANORAMA GENERAL DEL ANALISIS ORIENTADO AL OBJETO A. continuación se presenta una introducción rápida al Análisis Orientado al Objeto, o AOO. Veremos uno de los modelos gráficos más usados en este método en el orden en que se desarrolla comúnmente. 1.1 Definición del analisis Al construir un sistema grande de software típico, el analista generalmente tiene que manejar un número muy variable de dominios. Cada dominio se puede considerar un mundo aparte habitado por sus propias entidades conceptuales, u objetos. Por lo tanto, un Sistema Ferroviario de Manejo Automatizado, el dominio de las operaciones ferroviarias, está relacionado con trenes, vías y cosas por el estilo, mientras que un dominio de Interfaz del Usuario implica ventanas, desplegados y señalamientos. Cada dominio puede existir más o menos en forma independiente de los otros: - Una vía de tren puede existir sin pantallas o. ventanas. - Las ventanas y señalamientos pueden existir sin los trenes. En la figura se muestra un cuadro de dominios. Algunos dominios son lo suficientemente pequeños para ser analizados en conjunto, en tanto que otros contienen tantos objetos que no se pueden manejar. Por consiguiente, los dominios grandes se dividen en subsistemas, como se muestra en la matriz del projecto, en la figura Una vez que el sistema se ha dividido en dominios y subsistemas, estamos listos para proseguir con el análisis propio para cada uno. Cada subsistema' (o pequeño dominio) se analiza por separado en tres pasos: modelo de información, modelo de estado y modelo de proceso. En las siguiente secciones se describen estos pasos. 1.2 Modelos de informaoión El objetivo del paso de modelo de información es identificar las entidades conceptuales, u objetos, que componen el subsistema bajo análisis. Los objetos se describen en un modelo de información (figura 1.2.1) junto con sus características o atributos. Las relaciones entre los objetos se representan en el modelo gráfico como conexiones entre los objetos. Se debe elaborar una descripción completa o definición, de cada objeto, atributo y relación, como documentación para el modelo gráfico. 1

19 Figura 1.1.1:._ * * Cuadro de dominios para el Sistema Ferroviario de Manejo Automático. Cada dominio se representa en un Óvalo. La conexión entre dos dominios indica que el dominio más alto utilizará las instalaciones del dominio inferior en el sistema implantado. Dornmn / Figura 1.1.2: Matriz del proyecto para el Sistema Ferroviario de Manejo Automatizado. Los cuadros representan unidades de trabajo a realizar durante el análisis.

20 C _^. z Í, * Track segment IO (R11 Train O [Rll /' is I mibr t R6 f ' u7 Figura 1.2.1: Modelo de información parcial para el subsistema de operación ferroviaria. Un modelo típico de información tiene entre 20 y 60 objetos.. c. n: rms LO depea {wain 01 / -._ Figura 1.3.1: Te!l passenger cars LO wcura for dapertvre - Tell al passenger capo LO open dwrs Satumer bruma LO &pert. -_. - Modelo de estado para el objeto tren. - ~

21 1.3 Modelos Be estado Una vez identificados los objetos y relaciones, nos dirigimos a la investigación de su comportamiento al pasar del tiempo. En el A00 cada objeto y relación pude tener un ciclo de vida, un patrón ordenado de comportamiento. Por ejemplo, un tren que está corriendo a lo largo de las vías debe reducir la velocidad cuando entra a una estación; cuando ha llegado a la plataforma, el tren se detiene antes de abrir las puertas; después se puede preparar para partir haciendo sonar los timbres o campanas o indicando a los pasajeros que la partida está a punto de realizarse. Por Último, las puertas se deben cerrar antes de que el tren deje la estación. Este ciclo de vida se formaliza en un modelo de estado: un grupo de estados y sucesos. Un estado representa una situación o condición del objeto durante la cual se aplican ciertas leyes físicas, reglas y políticas. Un suceso representa un incidente que hace que el objeto de mueva de un estado a otro. Para cada objeto y relación se construye un modelo de estado separado que tiene un comportamiento dinámico separado. En la figura se muestra un modelo de estado para el objeto tren. Observe que alguna actividad se ha asociado con cada estado. Esta actividad, denominada adecuadamente acción, se da cuando el objeto llega en el estado. Con el fin de lograr un comportamiento coordinado entre los diferentes objetos, se permite que los estados modelos se comuniquen entre sí mediante sucesos: el modelo de estado tren puede generar un suceso hacia la puerta para indicarle que se abra. Dicha comunicación se representa en el modelo de comunicación objeto (figura 1.3.2). Para cada subsistema se construye un modelo de comunicación para el objeto. Una vez que se han desarrollado modelos de comunicación del objeto para todos los subsistemas en un dominio, se puede retirar un modelo de comunicación del subsistema para describir la comunicación de sucesos entre los subsistemas. En la figura se muestra un modelo de comunicación de un subsistema. 1.4 Modelos de proceso Todo el procesamiento en el sistema está contenido en acciones. de los modelos de estado. Cada acción enseguida es definida en términos de almacenes de información sobre los procesos y objetos, en donde un proceso es una unidad fundamental de operación y un almacén de datos sobre el objeto corresponde a los datos (atributos) de un objeto en el modelo de información. Cada acción se describe gráficamente en el diagrama de flujo de datos sobre la acción (DFDA), como se muestra en la figura Observe que un DFDA aparte de produce para cada acción de cada modelo de estado. Los del procesos de una acción pueden tener acceso tanto a los datos objeto en cuyo modelo de estado están integrados como a los 2