Proyecto de InuetigacioQ I y

Tamaño: px
Comenzar la demostración a partir de la página:

Download "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

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

Para comenzar, abra el programa Inmediatamente aparecerá una ventana llamada editor de datos que tiene la siguiente forma:

Para comenzar, abra el programa Inmediatamente aparecerá una ventana llamada editor de datos que tiene la siguiente forma: 1. Descripción Generales del Paquete Estadístico SPSS. SPSS es un paquete estadístico orientado -en principio- al ámbito de aplicación de las Ciencias Sociales y que lleva en el mercado alrededor de 25

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

BASES DE DATOS. 1.1 Funciones de un DBMS

BASES DE DATOS. 1.1 Funciones de un DBMS BASES DE DATOS Un DBMS, son programas denominados Sistemas Gestores de Base de Datos, abreviado SGBD, en inglés Data Base Management System (DBMS) que permiten almacenar y posteriormente acceder a los

Más detalles

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS 4.1 Diferencias entre análisis y diseño La división entre el análisis y diseño es poco clara, el trabajo de los dos se mezcla continuamente

Más detalles

Índice. Acerca de PenReader... 2. Cómo empezar... 2. Ajustes de PenReader... 4. Estándar... 4. Perfiles... 5. Reconocimiento... 6. Registrar...

Índice. Acerca de PenReader... 2. Cómo empezar... 2. Ajustes de PenReader... 4. Estándar... 4. Perfiles... 5. Reconocimiento... 6. Registrar... Índice Acerca de PenReader... 2 Cómo empezar... 2 Ajustes de PenReader... 4 Estándar... 4 Perfiles... 5 Reconocimiento... 6 Registrar... 7 Acerca del programa... 7 Ajustes avanzados de reconocimiento...

Más detalles

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R índice Módulo A Unidad didáctica 1: Introducción a las Bases de Datos Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos 3 19 Módulo B Unidad didáctica 1: Fase de análisis de requisitos Modelo

Más detalles

Modelo Conceptual. También conocido como modelo de dominio. Diccionario/Glosario Diagrama de Entidad Relación Diagrama de Clases

Modelo Conceptual. También conocido como modelo de dominio. Diccionario/Glosario Diagrama de Entidad Relación Diagrama de Clases Modelo Conceptual Explica cuales son y como se relacionan los conceptos relevantes en la descripción del problema Existen muchas variantes, con distintos grados de sofisticación, para describir el modelo

Más detalles

Capítulo VI. Diagramas de Entidad Relación

Capítulo VI. Diagramas de Entidad Relación Diagramas de Entidad Relación Diagramas de entidad relación Tabla de contenido 1.- Concepto de entidad... 91 1.1.- Entidad del negocio... 91 1.2.- Atributos y datos... 91 2.- Asociación de entidades...

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos 3.3 EL MÉTODO DE BOOCH. 3.3. Introducción. El método cuenta con una notación expresiva y bien definida que le permite al diseñador comunicar sus ideas y concentrarse en problemas más serios. Para la captura

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

2.1 Ingeniería de Software

2.1 Ingeniería de Software Capítulo 2 Marco Teórico Se pretende desarrollar un software que pueda ser aplicado como una herramienta útil para la administración de una empresa. Es necesario tener en cuenta que, en todo desarrollo

Más detalles

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa.

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. BASES DE DATOS Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. La creación de una base de datos debe ser realizada cuidadosamente procurando

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

Planificación y Control de Proyectos de Software mediante MS Project

Planificación y Control de Proyectos de Software mediante MS Project Práctica 2 Planificación y Control de Proyectos de Software mediante MS Project E n esta práctica vamos a introducirnos en la Planificación y Control de Proyectos de Software mediante herramientas informáticas

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

PROGRAMACION ORIENTADA A OBJETOS CON PHP

PROGRAMACION ORIENTADA A OBJETOS CON PHP PROGRAMACION ORIENTADA A OBJETOS CON PHP COMO SE DEFINE EN PHP La programación orientada a objetos es una metodología de programación avanzada y bastante extendida, en la que los sistemas se modelan creando

Más detalles

PROGRAMACIÓN BÁSICA DE LA COMPUTADORA. 1 Introducción. Tabla 1: Instrucciones MIPS

PROGRAMACIÓN BÁSICA DE LA COMPUTADORA. 1 Introducción. Tabla 1: Instrucciones MIPS PROGRAMACIÓN BÁSICA DE LA COMPUTADORA 1 Introducción Un sistema de computadora total incluye tanto circuitería (hardware) como programación (software). El hardware consta de los componentes físicos y todo

Más detalles

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar MODELADO DE OBJETOS Bibiana ROSSI, Paola BRITOS y Ramón GARCIA MARTINEZ, CAPIS - Centro de Actualizacion Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. 0. INTRODUCCION {brossi,pbritos,rgm}@itba.edu.ar

Más detalles

Unidad 1. Introducción a los conceptos de Bases de Datos

Unidad 1. Introducción a los conceptos de Bases de Datos Unidad 1 Introducción a los conceptos de Bases de Datos 1.1 Definición de Base de Datos Dato: Conjunto de caracteres con algún significado, pueden ser numéricos, alfabéticos, o alfanuméricos. Información:

Más detalles

Ejemplo: agencia de viajes por internet

Ejemplo: agencia de viajes por internet Introducción Modelado de casos de uso Propósito y definición Casos de uso y extracción de requisitos Carácter hipotético de los casos de uso El modelo de casos de uso Notación. Actores y casos de uso.

Más detalles

Diseño orientado a los objetos

Diseño orientado a los objetos Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia

Más detalles

DISENO RELACIONAL DE BASES DE DATOS

DISENO RELACIONAL DE BASES DE DATOS DISENO RELACIONAL DE BASES DE DATOS 3. DISEÑO RELACIONAL DE BASES DE DATOS. El desarrollo de Bases de Datos es un enfoque TOP-DOWN, que transforma los requerimientos de información en una base de datos

Más detalles

PATRONES. Experto. Solución:

PATRONES. Experto. Solución: PATRONES. Experto. Asignar una responsabilidad a la clase que tiene la información necesaria para cumplirla. Cuál es el principio fundamental en virtud del cual asignaremos las responsabilidades a los

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

Metodologías utilizadas en la Búsqueda de Documentos

Metodologías utilizadas en la Búsqueda de Documentos Metodologías utilizadas en la Búsqueda de Documentos Nuestro propósito con este estudio es el de explicar los distintos métodos de que disponemos para buscar y recuperar documentos en las Empresas y Organizaciones.

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

Introducción a la Programación Orientada a Objetos

Introducción a la Programación Orientada a Objetos Introducción a la Programación Orientada a Objetos 1 IMPORTANTE NOTA PRELIMINAR Luis R. Izquierdo Este documento es un apéndice de mi proyecto fin de carrera. Lo escribí después de leer tres o cuatro libros

Más detalles

Introducción. Primera aproximación a los conceptos Orientados a Objetos

Introducción. Primera aproximación a los conceptos Orientados a Objetos Desarrollo de juegos como base para la compresión de temas fundamentales de la programación orientada a objetos Ponencia Aprendizaje y currículo HÉCTOR FABIO CADAVID RENGIFO ESCUELA COLOMBIANA DE INGENIERÍA

Más detalles

Principios Básicos de Contabilidad Capítulo 1 Iniciando Contabilidad DacEasy DacEasy Contabilidad Versión 11

Principios Básicos de Contabilidad Capítulo 1 Iniciando Contabilidad DacEasy DacEasy Contabilidad Versión 11 Principios Básicos de Contabilidad Capítulo 1 Iniciando Contabilidad DacEasy DacEasy Contabilidad Versión 11 Si entiendes los principios básicos de contabilidad, será capaz de hacer el mejor uso de su

Más detalles

Protección para la base de datos CRM de GoldMine utilizando DbDefence

Protección para la base de datos CRM de GoldMine utilizando DbDefence Protección para la base de datos CRM de GoldMine utilizando DbDefence Versión 1.0, 1 junio 2013 Introducción Representando la columna vertebral de toda empresa digital, las bases de datos son esenciales

Más detalles

ETIQUETA DISEÑO DE PÁGINA

ETIQUETA DISEÑO DE PÁGINA ETIQUETA DISEÑO DE PÁGINA Es la tercera etiqueta de Excel 2007, agrupa las herramientas de temas 10, configuración de pagina, ajustes del área de impresión, opciones de la hoja (cuadriculas y encabezados),

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

SESIÓN PRÁCTICA 2: MANEJO DEL VISOR DE RESULTADOS, VENTANAS DE SINTAXIS Y GRÁFICAS PROBABILIDAD Y ESTADÍSTICA. PROF. Esther González Sánchez

SESIÓN PRÁCTICA 2: MANEJO DEL VISOR DE RESULTADOS, VENTANAS DE SINTAXIS Y GRÁFICAS PROBABILIDAD Y ESTADÍSTICA. PROF. Esther González Sánchez SESIÓN PRÁCTICA 2: MANEJO DEL VISOR DE RESULTADOS, VENTANAS DE SINTAXIS Y GRÁFICAS PROBABILIDAD Y ESTADÍSTICA PROF. Esther González Sánchez Departamento de Informática y Sistemas Facultad de Informática

Más detalles

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software Principio de Diseño Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002 Introducción al Diseño de Software Qué es el diseño? Representación ingenieril

Más detalles

SISTEMATIZACIÓN DE LA GENERACIÓN DE PRESUPUESTOS PARA PROYECTOS DE OBRA: DOCUMENTO DE VISIÓN SISTEMA DE ADMINISTRACIÓN DE MATERIALES DE TUBERÍA

SISTEMATIZACIÓN DE LA GENERACIÓN DE PRESUPUESTOS PARA PROYECTOS DE OBRA: DOCUMENTO DE VISIÓN SISTEMA DE ADMINISTRACIÓN DE MATERIALES DE TUBERÍA SISTEMATIZACIÓN DE LA GENERACIÓN DE PRESUPUESTOS PARA PROYECTOS DE OBRA: SISTEMA DE ADMINISTRACIÓN DE MATERIALES DE TUBERÍA PARA INARGOS LTDA. DOCUMENTO DE VISIÓN VERSIÓN 1.3 BOGOTÁ, COLOMBIA, ENERO 2012

Más detalles

FUNDAMENTOS DE LA TEORÍA DE SISTEMA

FUNDAMENTOS DE LA TEORÍA DE SISTEMA FUNDAMENTOS DE LA TEORÍA DE SISTEMA AL TERMINAR LA CLASE UD PODRÁ RESPONDER Qué es un sistema? Cómo pueden ser definidos los sistemas? Cuáles son los parámetros de un sistema? Cuáles son las característica

Más detalles

Weitzenfeld: Capítulo 6 1

Weitzenfeld: Capítulo 6 1 Weitzenfeld: Capítulo 6 Las descripciones de los casos de uso representan todas las posibles interacciones de los actores con el sistema para los eventos enviados o recibidos por los actores. En esta etapa

Más detalles

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

Cómo hacer un mapa conceptual paso a paso

Cómo hacer un mapa conceptual paso a paso Esta guía corresponde a una adaptación de la guía Cómo hacer un mapa conceptual paso a paso de Talleres de adaptación e innovación tecnológica para el Espacio Europeo de Educación Superior IUED - UNED

Más detalles

La Arquitectura de las Máquinas Virtuales.

La Arquitectura de las Máquinas Virtuales. La Arquitectura de las Máquinas Virtuales. La virtualización se ha convertido en una importante herramienta en el diseño de sistemas de computación, las máquinas virtuales (VMs) son usadas en varias subdiciplinas,

Más detalles

Manual del Usuario de Microsoft Access Introducción - Página 1. I. Introducción. I.1. Base de Datos Relacional

Manual del Usuario de Microsoft Access Introducción - Página 1. I. Introducción. I.1. Base de Datos Relacional Manual del Usuario de Microsoft Access Introducción - Página 1 I. Introducción I.1. Base de Datos Relacional Una base de datos relacional es una colección de información secundaria a un tema o propósito

Más detalles

CAPITULO 3 DISEÑO. El diseño del software es el proceso que permite traducir los requisitos

CAPITULO 3 DISEÑO. El diseño del software es el proceso que permite traducir los requisitos 65 CAPITULO 3 DISEÑO 3.1. DISEÑO El diseño del software es el proceso que permite traducir los requisitos analizados de un sistema en una representación del software. 66 Diseño procedural Diseño de la

Más detalles

Creación de redes AirPort 2

Creación de redes AirPort 2 apple Creación de redes AirPort 2 Contenido 1 Introducción 5 Acerca de AirPort 5 Cómo funciona AirPort 6 Cómo se proporciona acceso inalámbrico a Internet 6 Configuración del acceso a Internet de la estación

Más detalles

6.5 Modelo del dominio del problema

6.5 Modelo del dominio del problema 6.5 Modelo del dominio del problema El modelo del dominio del problema define un modelo de clases comun para todos los involucrados en el modelo de requisites, tanto analistas como clientes. Este modelo

Más detalles

ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION

ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION UNIDAD V ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION Contenido: 5.1 Introducción 5.2 Principios del Análisis 5.3 Construcción de Prototipos del Software 5.4 Métodos de Análisis de Requisitos 5.5 La Especificación

Más detalles

Qué se entiende por diseño arquitectónico? Comprende el establecimiento de un marco de trabajo estructural básico para un sistema. Alude a la estructura general del software y el modo en que la estructura

Más detalles

6.6 DISEÑO. [Proceso]

6.6 DISEÑO. [Proceso] 6.6 DISEÑO. [Proceso] Durante un Ciclo de Desarrollo iterativo es posible pasar a la Fase de Diseño una vez completada la documentación de la fase de Análisis. Durante esta etapa se desarrolla una solución

Más detalles

EL AULA VIRTUAL COMO RECURSO DIDÁCTICO

EL AULA VIRTUAL COMO RECURSO DIDÁCTICO EL AULA VIRTUAL COMO RECURSO Autoría: DEL CAMPO LÓPEZ, BERNARDINO, IES JULIO REY PASTOR, ALBACETE. b.delcampo@iesjrp.es Temática: TIC Palabras clave: TIC, MOODLE, AULA VIRTUAL, ALTHIA. Resumen Esta comunicación

Más detalles

1. Se debe plantear sobre el papel la solución del ejercicio.

1. Se debe plantear sobre el papel la solución del ejercicio. CIUDAD UNIVERSITARIA s/n Aptdo. 60.149 28080 MADRID UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA Escuela Universitaria de Informática Practicas y Pruebas de Evaluación a Distancia En este apartado se

Más detalles

Infocentro para el fortalecimiento de la red de micro y pequeñas empresas de la comuna de Ancud MANUAL DE ACCESS ILUSTRE MUNICIPALIDAD DE ANCUD

Infocentro para el fortalecimiento de la red de micro y pequeñas empresas de la comuna de Ancud MANUAL DE ACCESS ILUSTRE MUNICIPALIDAD DE ANCUD Infocentro para el fortalecimiento de la red de micro y pequeñas empresas de la comuna de Ancud MANUAL DE ACCESS ILUSTRE MUNICIPALIDAD DE ANCUD DIRECCIÓN DE DESARROLLO ECONOMICO Y FOMENTO PRODUCTIVO OPTIMICE

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción El WWW es la mayor fuente de imágenes que día a día se va incrementando. Según una encuesta realizada por el Centro de Bibliotecas de Cómputo en Línea (OCLC) en Enero de 2005,

Más detalles

Microsoft Excel. Entrando Formulas y Funciones

Microsoft Excel. Entrando Formulas y Funciones M Microsoft Excel icrosoft Excel es una poderosa hoja de cálculo que se usa para analizar y para resumir datos. Excel tiene funciones incorporadas que permiten que los usuarios realicen cálculos complejos,

Más detalles

Fundamentos del diseño de software

Fundamentos del diseño de software Fundamentos del diseño de software El diseño es el primer paso de la fase de desarrollo de cualquier producto o sistema de ingeniería. Definición de diseño según Taylor Proceso de aplicar distintas técnicas

Más detalles

CRM Customer Relationship Management

CRM Customer Relationship Management CRM Customer Relationship Management es la solución que ofrece IDSénia para gestionar su los clientes, como estrategia de negocio. Definición. Traducido como Gestión de la los clientes, es parte de una

Más detalles

Introducción a la P.O.O. Patrick Hernández Cuamatzi

Introducción a la P.O.O. Patrick Hernández Cuamatzi Introducción a la P.O.O. Patrick Hernández Cuamatzi Introducción } Debemos diferenciar entre Programación Orientada a Objetos (P.O.O.) y Lenguaje Orientado a Objetos (L.O.O.). } La P.O.O. es una filosofía,

Más detalles

Problemas indecidibles

Problemas indecidibles Capítulo 7 Problemas indecidibles 71 Codificación de máquinas de Turing Toda MT se puede codificar como una secuencia finita de ceros y unos En esta sección presentaremos una codificación válida para todas

Más detalles

ICONIX. Notas del método con ampliaciones y mejoras

ICONIX. Notas del método con ampliaciones y mejoras ICONIX Notas del método con ampliaciones y mejoras Juan Manuel Fernández Peña y María de los Ángeles Sumano López Colaboración de Josué Andrade Mirós Octubre de 2004 Método ICONIX Referencia El método

Más detalles

ARQUITECTURA DE SOFTWARE

ARQUITECTURA DE SOFTWARE ARQUITECTURA DE SOFTWARE Introducción n a la Arquitectura de Software (sistemas) Requisitos de calidad Documento de Diseño RTFS-Método del control de diseño Introducción n al Diseño o de la interfaz Humano/Computador

Más detalles

DATAWAREHOUSE Y DATAMINING: NUEVAS HERRAMIENTAS DE ANÁLISIS DE CLIENTES APLICADAS EN EL MARKETING ACTUAL

DATAWAREHOUSE Y DATAMINING: NUEVAS HERRAMIENTAS DE ANÁLISIS DE CLIENTES APLICADAS EN EL MARKETING ACTUAL Servicio Regional de Empleo CONSEJERÍA DE EMPLEO Y MUJER Comunidad de Madrid Curso Básico de MicroStrategy Desktop 07 de Marzo de 2.005 CÓDIGO: 04/5213 CURSO COFINANCIADO POR LA CONSEJERÍA DE EMPLEO Y

Más detalles

Introducción. Campos de Aplicación SGBD. Índice. Aplicaciones Representativas. Aplicaciones Representativas

Introducción. Campos de Aplicación SGBD. Índice. Aplicaciones Representativas. Aplicaciones Representativas SGBD Base de Un Sistema Gestor de consiste en: Datos Una colección de datos interrelacionados Un conjunto de programas para acceder a los datos Objetivo Principal de un SGBD: Proporcionar una forma práctica

Más detalles

Metodologías de diseño de hardware

Metodologías de diseño de hardware Capítulo 2 Metodologías de diseño de hardware Las metodologías de diseño de hardware denominadas Top-Down, basadas en la utilización de lenguajes de descripción de hardware, han posibilitado la reducción

Más detalles

CL_50466 Windows Azure Solutions with Microsoft Visual Studio 2010

CL_50466 Windows Azure Solutions with Microsoft Visual Studio 2010 Windows Azure Solutions with Microsoft Visual Studio 2010 www.ked.com.mx Av. Revolución No. 374 Col. San Pedro de los Pinos, C.P. 03800, México, D.F. Tel/Fax: 52785560 Introducción Este curso es una introducción

Más detalles

Experimento 5 COMBINACIONES DE RESISTENCIAS. Objetivos. Introducción. Figura 1 Circuito con dos resistencias en serie

Experimento 5 COMBINACIONES DE RESISTENCIAS. Objetivos. Introducción. Figura 1 Circuito con dos resistencias en serie Experimento 5 COMBINACIONES DE RESISTENCIAS Objetivos 1. Construir circuitos con baterías, resistencias, y cables conductores, 2. Analizar circuitos con combinaciones de resistencias en serie para verificar

Más detalles

Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera. Departamento de Lenguajes y Sistemas Informáticos

Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera. Departamento de Lenguajes y Sistemas Informáticos Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera Departamento de Lenguajes y Sistemas Informáticos INDICE 1. Introducción. 2. Documentación del Proyecto de Fin de

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Casos de Uso Un Método Práctico para Explorar Requerimientos Santiago Ceria 1. Introducción 1.1. Objetivo de este apunte En uno de los párrafos más citados del artículo por lejos

Más detalles

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño El proceso de diseño para una base de datos consta básicamente de 7 pasos, los cuáles se describen en la siguiente imagen.

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Información básica. Qué es un disco duro?

Información básica. Qué es un disco duro? Este capítulo presenta conceptos que usted debe entender para utilizar Drive Image con éxito. Entre ellos se incluyen: Qué es un disco duro? Cómo se almacenan y recuperan los datos? Qué es el formateo

Más detalles

BASES DE DATOS MIS 308

BASES DE DATOS MIS 308 2. MODELOS DE DATOS Introducción 2.1 Entidad relación 2.2 Jerárquico 2.3 De red 2.4 Relacional Introducción Hoy en día las empresas manejan una gran cantidad de datos. Cualquier empresa que se precie debe

Más detalles

El diseño de la base de datos de un Data Warehouse. Marta Millan millan@eisc.univalle.edu.co www.eisc.univalle.edu.co/materias

El diseño de la base de datos de un Data Warehouse. Marta Millan millan@eisc.univalle.edu.co www.eisc.univalle.edu.co/materias El diseño de la base de datos de un Data Warehouse Marta Millan millan@eisc.univalle.edu.co www.eisc.univalle.edu.co/materias El modelo Multidimensional Principios básicos Marta Millan millan@eisc.univalle.edu.co

Más detalles

El Modelo Conceptual

El Modelo Conceptual El Modelo Conceptual Ilustra: Conceptos (Objetos) en el dominio del problema. Es el instrumento (artefacto) más importante de crear en el AOO. Es la representación de cosas del mundo real y NO de componentes

Más detalles

Locker Room: Una Herramienta Para El Aprendizaje de Punteros Basada en La Metáfora de Las Taquillas

Locker Room: Una Herramienta Para El Aprendizaje de Punteros Basada en La Metáfora de Las Taquillas Locker Room: Una Herramienta Para El Aprendizaje de Punteros Basada en La Metáfora de Las Taquillas Carlos Martín Villanova, Tonghong Li, Claudio Soriente, Ricardo Jiménez Peris and Marta Patiño Martínez

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

Secretaría Virtual de la Asociación Española de Pediatría

Secretaría Virtual de la Asociación Española de Pediatría Secretaría Virtual de la Asociación Española de Pediatría Manual de uso versión 2.1 Fecha de actualización, 07/09/2012 Índice Introducción...1 Estructura de la Secretaría Virtual...2 Funciones de la Secretaría

Más detalles

INTRODUCCION A LAS BASES DE DATOS Procesamiento de Archivos vs Bases de Datos ARCHIVOS BASES DE DATOS

INTRODUCCION A LAS BASES DE DATOS Procesamiento de Archivos vs Bases de Datos ARCHIVOS BASES DE DATOS INTRODUCCION A LAS BASES DE DATOS Procesamiento de Archivos vs Bases de Datos ARCHIVOS Datos repetidos. No se manejan estándares. Había inconsistencia de datos. Falta de seguridad en los datos. No existían

Más detalles

GUIA DE OPERACIÓN DEL SISTEMA FeMexico

GUIA DE OPERACIÓN DEL SISTEMA FeMexico GUIA DE OPERACIÓN DEL SISTEMA FeMexico PAGINA DE INICIO La página de inicio le despliega en forma permanente los siguientes datos: Documento para el que esta configurado (Facturas, Recibos Honorarios o

Más detalles

Fundamento de Informática Teórica(2003) Prof. Dr. Eric Jeltsch F. ORGANIZACION FISICA DE LOS SISTEMAS DE BASE DE DATOS

Fundamento de Informática Teórica(2003) Prof. Dr. Eric Jeltsch F. ORGANIZACION FISICA DE LOS SISTEMAS DE BASE DE DATOS ORGANIZACION FISICA DE LOS SISTEMAS DE BASE DE DATOS La organización física de una base de datos es un tópico extenso y se aborda en detalle, principalmente en la asignatura Base de Datos, y digo principalmente

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS

PROGRAMACIÓN ORIENTADA A OBJETOS PROGRAMACIÓN ORIENTADA A OBJETOS Clase 1. Introducción Profesor: Diego Sánchez Gómez Introducción a la programación orientada a objetos 1. Introducción a la programación orientada a objetos 2. Las clases

Más detalles

Introducción al Arte de las Ciencias de la Computación

Introducción al Arte de las Ciencias de la Computación 1 NOMBRE DE LA CLASE: Introducción al Arte de las Ciencias de la Computación Duración: 45-60 minutos : Preparación: 15 minutos Meta: Dar al curso una idea clara de qué son las Ciencias de la Computación

Más detalles

Creación de redes AirPort Extreme

Creación de redes AirPort Extreme Creación de redes AirPort Extreme Contenido 1 Introducción 5 Acerca de AirPort 5 Cómo funciona AirPort 6 Cómo se proporciona acceso inalámbrico a Internet 6 Configuración del acceso a Internet de la estación

Más detalles

UNIDAD Nº 4. Construcción de un Modelo Conceptual

UNIDAD Nº 4. Construcción de un Modelo Conceptual UNIDAD Nº 4 Construcción de un Modelo Conceptual 1. Introducción Un Modelo Conceptual explica (a sus creadores) los conceptos significativos en un dominio del problema, es el artefacto más importante a

Más detalles

Manual del Usuario de I*STAR Edición de Mayo, 2003 (Cubre la versión 3.1.85)

Manual del Usuario de I*STAR Edición de Mayo, 2003 (Cubre la versión 3.1.85) Manual del Usuario de I*STAR 1 Manual del Usuario de I*STAR Edición de Mayo, 2003 (Cubre la versión 3.1.85) 2 Manual del Usuario de I*STAR Derechos intelectuales 2002 LOMA (Life Office Management Association,

Más detalles

Programa de Ingeniería de Sistemas Ingeniería de Software I

Programa de Ingeniería de Sistemas Ingeniería de Software I DIAGRAMAS DE CLASES EJERCICIOS RESUELTOS. ----------------------------------------------------------------------------------------------------------------------------------------- EJERCICIO. RESERVA DE

Más detalles

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN Principios y criterios para la evaluación del ciclo de vida de desarrollo de sistemas Se pueden enunciar algunos principios para desarrollar

Más detalles

FiberGIS. 1. Administrador de Seguridad y Parámetros. 2. Módulo de Mantenimiento de Redes. 2.1. Funcionalidad. 2.2.

FiberGIS. 1. Administrador de Seguridad y Parámetros. 2. Módulo de Mantenimiento de Redes. 2.1. Funcionalidad. 2.2. FiberGIS Este sistema permite administrar desde una aplicación gráfica y amigable los componentes de infraestructura y lógicos de una red de fibra óptica. La aplicación gestiona simultáneamente la información

Más detalles

ERRORES MÁS COMUNES QUE SE COMETEN EN LA REDACCIÓN DE PROYECTOS Y ANTEPROYECTOS DE INVESTIGACIÓN

ERRORES MÁS COMUNES QUE SE COMETEN EN LA REDACCIÓN DE PROYECTOS Y ANTEPROYECTOS DE INVESTIGACIÓN ERRORES MÁS COMUNES QUE SE COMETEN EN LA REDACCIÓN DE PROYECTOS Y ANTEPROYECTOS DE INVESTIGACIÓN POR GILBERTO CASTRO QUINTERO Profesor Asociado UNIVERSIDAD NACIONAL DE COLOMBIA SEDE MEDELLÍN TABLA DE CONTENIDO

Más detalles

ÍNDICE INTRODUCCIÓN 3 EJEMPLOS DE PREGUNTAS DE RESOLUCION DE PROBLEMAS 4

ÍNDICE INTRODUCCIÓN 3 EJEMPLOS DE PREGUNTAS DE RESOLUCION DE PROBLEMAS 4 ÍNDICE Pág. INTRODUCCIÓN 3 EJEMPLOS DE PREGUNTAS DE RESOLUCION DE PROBLEMAS 4 Climatizador 5 Billetes 8 Tráfico 12 Robot de limpieza 15 Reproductor MP3 18 Fiesta de cumpleaños 22 2 INTRODUCCIÓN En el presente

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

Proceso de desarrollo del software modelo en cascada

Proceso de desarrollo del software modelo en cascada Proceso de desarrollo del software modelo en cascada Análisis: Necesidades del usuario especificaciones Diseño: Descomposición en elementos que puedan desarrollarse por separado especificaciones de cada

Más detalles

a) Cita y comenta brevemente los grados de acoplamiento. Clasifícalos y ordénalos en orden creciente al nivel de acoplamiento asociado.

a) Cita y comenta brevemente los grados de acoplamiento. Clasifícalos y ordénalos en orden creciente al nivel de acoplamiento asociado. Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE II: CONCEPTOS TEÓRICOS Y PRÁCTICOS DNI Apellidos y nombre 1. Responde a las siguientes cuestiones (2 puntos): a) Cita y comenta brevemente

Más detalles

3. CÁLCULOS Y FORMATOS CONDICIONALES

3. CÁLCULOS Y FORMATOS CONDICIONALES colores, tendremos las opciones Mínima y Máxima, con tres campos cada una: Tipo, Valor y Color. Con este formato podemos crear una regla que le asigne un color al menor valor y otro al mayor, y dé a los

Más detalles