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

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

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

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

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

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

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

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

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

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

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

TABLA DE DECISION. Consideremos la siguiente tabla, expresada en forma genérica, como ejemplo y establezcamos la manera en que debe leerse.

TABLA DE DECISION. Consideremos la siguiente tabla, expresada en forma genérica, como ejemplo y establezcamos la manera en que debe leerse. TABLA DE DECISION La tabla de decisión es una herramienta que sintetiza procesos en los cuales se dan un conjunto de condiciones y un conjunto de acciones a tomar según el valor que toman las condiciones.

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

El modelo de ciclo de vida cascada, captura algunos principios básicos:

El modelo de ciclo de vida cascada, captura algunos principios básicos: 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 de desarrollo de software. El primer ciclo de vida del software, "Cascada",

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

Preparándose para el Aprendizaje en Línea (e-learning) Guía del Participante

Preparándose para el Aprendizaje en Línea (e-learning) Guía del Participante Preparándose para el Aprendizaje en Línea (e-learning) Guía del Participante Crescenciano Olvera Contenido. Propósito y Objetivos...3 Guía del Estudiante - Introducción...4 Acceso al sitio Web de los cursos....4

Más detalles

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los

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

ADENDUM A LA UNIDAD 6 MODELOS CONCEPTUALES

ADENDUM A LA UNIDAD 6 MODELOS CONCEPTUALES ADENDUM A LA UNIDAD 6 MODELOS CONCEPTUALES A6. MODELOS ORIENTADOS A PROCESOS... 1 A6.1. INTRODUCCIÓN AL MODELADO CONCEPTUAL... 2 A6.1.1. CONCEPTO DE MODELO... 2 A6.1.2. PROPÓSITO DE LOS MODELOS... 2 A6.1.3.

Más detalles

Logística Computación I Pág.: 1 FUNCIÓN AUTORRESUMEN

Logística Computación I Pág.: 1 FUNCIÓN AUTORRESUMEN Computación I Pág.: 1 FUNCIÓN AUTORRESUMEN La Función Autorresumen se usa para confeccionar automáticamente resúmenes con los principales puntos de un documento. Esta función analiza el documento según

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

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

CAPITULO V DISEÑO DEL CUADRO DE MANDO INTEGRAL

CAPITULO V DISEÑO DEL CUADRO DE MANDO INTEGRAL CAPITULO V DISEÑO DEL CUADRO DE MANDO INTEGRAL Al hablar del balance scorecard, no deberíamos referirnos al mismo como Proyecto, sino más bien como Programa. Esto solamente para dar al balanced scorecard

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

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

Proyectos de inversión. Economía de la Empresa (ISS)

Proyectos de inversión. Economía de la Empresa (ISS) Proyectos de inversión Economía de la Empresa (ISS) 1 Categorías de Flujo de Efectivo El flujo de caja flujos suelen contener las siguientes categorías de flujo de caja. Estas categorías se describen para

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

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

Las 7 Herramientas Fundamentales de la Calidad

Las 7 Herramientas Fundamentales de la Calidad Las 7 Herramientas Fundamentales de la Calidad Se utilizarán los métodos estadísticos elementales, dado que está dirigido a todos los funcionarios, desde la alta dirección hasta los operarios de base (Ej:

Más detalles

Arquitectura y seguridad

Arquitectura y seguridad En el desarrollo del SIGOB nos hemos enfrentado a diversos problemas que nos han llevado a investigar y desarrollar nuestras propias tecnologías. En este documento presentamos cada uno de los desarrollos

Más detalles

Modelado con Casos de Uso (CU)

Modelado con Casos de Uso (CU) Universidad de Congreso Modelado con Casos de Uso (CU) Análisis de Sistemas 2do año Qué es el modelado de Casos de uso? Una forma de capturar el comportamiento deseado del sistema a desarrollar Una manera

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

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

Lecturas previas Cuando llegue a su primera sesión de laboratorio debe haber estudiado el contenido de la lectura que aparece a continuación.

Lecturas previas Cuando llegue a su primera sesión de laboratorio debe haber estudiado el contenido de la lectura que aparece a continuación. Laboratorio 1 Medición e incertidumbre La descripción de los fenómenos naturales comienza con la observación; el siguiente paso consiste en asignar a cada cantidad observada un número, es decir en medir

Más detalles

Workflow, BPM y Java Resumen de la presentación de Tom Baeyens

Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Página 1 de 11 1. Introducción Tom Baeyens es el fundador y arquitecto del proyecto de JBoss jbpm, la máquina de workflow

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

1000 + 900 + 90 + 7 = 1997

1000 + 900 + 90 + 7 = 1997 ases Matemáticas I - Pagina 1 de 20 Tema 2: ases Matemáticas I. 2.1.- Números utilizados en los sistemas digitales. 2.1.1 Introducción. El sistema de numeración decimal es familiar a todo el mundo. Este

Más detalles

Límites. Definición de derivada.

Límites. Definición de derivada. Capítulo 4 Límites. Definición de derivada. 4.1. Límites e indeterminaciones Hemos visto en el capítulo anterior que para resolver el problema de la recta tangente tenemos que enfrentarnos a expresiones

Más detalles

Ingeniería del Software I

Ingeniería del Software I - 1 - Ingeniería del Software I Introducción al Modelo Conceptual 2do. Cuatrimestre 2005 INTRODUCCIÓN... 2 CLASES CONCEPTUALES... 3 ESTRATEGIAS PARA IDENTIFICAR CLASES CONCEPTUALES... 3 Utilizar lista

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

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

FUNCIONES 1. DEFINICION DOMINIO Y RANGO

FUNCIONES 1. DEFINICION DOMINIO Y RANGO 1. DEFINICION DOMINIO Y RANGO FUNCIONES Antes de definir función, uno de los conceptos fundamentales y de mayor importancia de todas las matemáticas, plantearemos algunos ejercicios que nos eran de utilidad

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

El rincón de los problemas. Nuevos horizontes matemáticos mediante variaciones de un problema

El rincón de los problemas. Nuevos horizontes matemáticos mediante variaciones de un problema www.fisem.org/web/union El rincón de los problemas ISSN: 1815-0640 Número 35. Septiembre de 2013 páginas 135-143 Pontificia Universidad Católica del Perú umalasp@pucp.edu.pe Nuevos horizontes matemáticos

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

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

INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN

INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN INDICE Introducción...2 Frontera de la aplicación...3 Cuenta de Puntos Función sin ajustar...3 Funciones de Datos...4 Funciones Transaccionales...4 Mecanismo...5

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

Guía de importación de datos

Guía de importación de datos Guía de importación de datos Contenido Introducción... 2 Paso 1. Preparación de datos... 2 Paso 2. Control de importación de datos... 5 Paso 3. Validación del archivo de datos... 6 Paso 4. Asignación de

Más detalles

Admincontrol Servicios

Admincontrol Servicios Admincontrol Servicios P á g i n a 1 Table of Contents Introducción.... 2 Ventana principal de Quanticus Admincontrol SERVICIOS.... 3 Configuración de Quanticus Admincontrol SERVICIOS.... 5 1. Configurar

Más detalles

Patrones de Diseño Orientados a Objetos 2 Parte

Patrones de Diseño Orientados a Objetos 2 Parte Patrones de Diseño Orientados a Objetos 2 Parte Patrón Observador Observer (Patrón de Comportamiento) Patrón Observador Observer Observador (en inglés: Observer) es un patrón de diseño que define una dependencia

Más detalles

Decisión: Indican puntos en que se toman decisiones: sí o no, o se verifica una actividad del flujo grama.

Decisión: Indican puntos en que se toman decisiones: sí o no, o se verifica una actividad del flujo grama. Diagrama de Flujo La presentación gráfica de un sistema es una forma ampliamente utilizada como herramienta de análisis, ya que permite identificar aspectos relevantes de una manera rápida y simple. El

Más detalles

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007 Enunciado Se desea efectuar el testing funcional de un programa que ejecuta transferencias entre cuentas bancarias. El programa recibe como parámetros la cuenta de origen, la de cuenta de destino y el

Más detalles

UNIDAD 1. LOS NÚMEROS ENTEROS.

UNIDAD 1. LOS NÚMEROS ENTEROS. UNIDAD 1. LOS NÚMEROS ENTEROS. Al final deberás haber aprendido... Interpretar y expresar números enteros. Representar números enteros en la recta numérica. Comparar y ordenar números enteros. Realizar

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

MANUAL DE UTILIZACIÓN DEL CRM

MANUAL DE UTILIZACIÓN DEL CRM MANUAL DE UTILIZACIÓN DEL CRM ÍNDICE Qué es un CRM 1. Acceso al CRM 2. Organización del CRM 3. Portada 4. Prospectos 5. Clientes 6. Créditos 7. Emails 8. Documentos 9. Calendario 10. Ejemplos de Utilización

Más detalles

INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION

INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION. Los sistemas que el analista diseña día a día, la tecnología, las personas, que utilizan el

Más detalles

UNIDADES DE ALMACENAMIENTO DE DATOS

UNIDADES DE ALMACENAMIENTO DE DATOS 1.2 MATÉMATICAS DE REDES 1.2.1 REPRESENTACIÓN BINARIA DE DATOS Los computadores manipulan y almacenan los datos usando interruptores electrónicos que están ENCENDIDOS o APAGADOS. Los computadores sólo

Más detalles

Interoperabilidad de Fieldbus

Interoperabilidad de Fieldbus 2002 Emerson Process Management. Todos los derechos reservados. Vea este y otros cursos en línea en www.plantwebuniversity.com. Fieldbus 201 Interoperabilidad de Fieldbus Generalidades Qué es interoperabilidad?

Más detalles

Guía de funciones básicas en SalesUp!

Guía de funciones básicas en SalesUp! 1 Guía de funciones básicas en SalesUp! SalesUp! 2 TE DAMOS LA BIENVENIDA A TU CUENTA Vas a descubrir porqué miles de ejecutivos de ventas han incrementado su productividad y disfrutado los beneficios

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

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

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

Arquitectura para análisis de información. Zombi es una arquitectura que proporciona de manera integrada los componentes

Arquitectura para análisis de información. Zombi es una arquitectura que proporciona de manera integrada los componentes Capítulo 4 Arquitectura para análisis de información propuesta 4.1 Arquitectura Zombi es una arquitectura que proporciona de manera integrada los componentes necesarios para el análisis de información

Más detalles

Diseño Estructurado de Sistemas

Diseño Estructurado de Sistemas El diseño estructurado de sistemas se ocupa de la identificación, selección y organización de los módulos y sus relaciones. Se comienza con la especificación resultante del proceso de análisis, se realiza

Más detalles

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Modulo 03 UML: Vista de Casos de Uso Artefacto: Actores Catedrático MSC. Jose Juan Aviña Grimaldo e-mail josejuan_avina@gmail.com

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

SISTEMAS DE INFORMACIÓN I TEORÍA

SISTEMAS DE INFORMACIÓN I TEORÍA CONTENIDO: CICLO DE VIDA DE DESARROLLO DE SI FASES GENÉRICAS DEL CICLO DE VIDA DE DESARROLLO DE SI VISIÓN TRADICIONAL DEL CICLO DE VIDA DE DESARROLLO DE SI DE DESARROLLO DE SI: ANÁLISIS Material diseñado

Más detalles

Codd propuso estos tres lenguajes como base teórica de cualquier lenguaje que quisiera cumplir con los requisitos formales del modelo.

Codd propuso estos tres lenguajes como base teórica de cualquier lenguaje que quisiera cumplir con los requisitos formales del modelo. 16/05/2012 1 Todo modelo de datos debe definir un lenguaje de definición de datos para crear las estructuras donde se almacenará la información y un lenguaje de manipulación de datos con el que acceder

Más detalles

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

Contenido. Samayra Niebles Velasquez chamayra@hotmail.com www.insser.net

Contenido. Samayra Niebles Velasquez chamayra@hotmail.com www.insser.net Contenido MACROS EN MS EXCEL... 1 Objetos, propiedades y métodos... 1 Propiedades... 1 Métodos.... 1 Editor de Visual Basic.... 2 Insertar un nuevo módulo.... 2 Insertar un procedimiento.... 2 Ejecutar

Más detalles

Análisis de Requerimientos

Análisis de Requerimientos Análisis de Requerimientos Ing. Luis Zuloaga Rotta Situación de la Industria de Software Mas del 30% de todos los proyectos de software son cancelados antes de su finalización. Mas del 70% de los proyectos

Más detalles

Planeación de Help Desk

Planeación de Help Desk Planeación de Help Desk Antes de empezar formalmente a ayudar a otros con problemas de computadores, debe tomar ciertas decisiones previas. Es necesario que entienda la importancia de trabajar con los

Más detalles

Creación de Funciones de Conducción

Creación de Funciones de Conducción Creación de Funciones de Conducción Requerimientos Para el desarrollo de esta actividad se requiere que: Contemos con un robot BoeBot armado con placa Arduino. Repetición En estos momentos habremos notado

Más detalles

Actualización de Windows XP a Windows 7

Actualización de Windows XP a Windows 7 La actualización del equipo de Windows XP a Windows 7 requiere una instalación personalizada que no conserva los programas, los archivos ni la configuración. Por esa razón, a menudo se la denomina instalación

Más detalles

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS CURSO: JAVA BASICO PROFESOR: EMERSON CASTAÑEDA SANABRIA TEMA: Programación Orientada a Objetos OBJETIVOS: Familiarizarse con la Programación

Más detalles

Modelado de datos Relacional Modelado de datos Orientado a Objeto Modelado de datos Objeto-Relacional

Modelado de datos Relacional Modelado de datos Orientado a Objeto Modelado de datos Objeto-Relacional 2. 1 Modelado de Datos El manejo de información implica el saber como organizar los datos. Un apoyo lo encontramos en las herramientas de bases de datos que a su vez se apoyan en el modelo de datos. Para

Más detalles

CC es la abreviación de Cyber Café. Es así como nos referimos al programa en este documento.

CC es la abreviación de Cyber Café. Es así como nos referimos al programa en este documento. Preguntas Frecuentes Generales?? Qué significa CC? CC es la abreviación de Cyber Café. Es así como nos referimos al programa en este documento.?? Cuáles son los requerimientos mínimos de hardware para

Más detalles

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

Más detalles

Creación y administración de grupos de dominio

Creación y administración de grupos de dominio Creación y administración de grupos de dominio Contenido Descripción general 1 a los grupos de Windows 2000 2 Tipos y ámbitos de los grupos 5 Grupos integrados y predefinidos en un dominio 7 Estrategia

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

Análisis de Requisitos

Análisis de Requisitos Análisis de Requisitos Los requisitos determinan lo que hará el sistema y definen restricciones sobre su operación e implementación. El análisis de requisitos es el proceso del estudio de las necesidades

Más detalles

Unidad II. Metodología para resolver problemas aplicando la POO. Parte 3 Análisis del Problema Modelo del Dominio

Unidad II. Metodología para resolver problemas aplicando la POO. Parte 3 Análisis del Problema Modelo del Dominio Unidad II Metodología para resolver problemas aplicando la POO Parte 3 Análisis del Problema Modelo del Dominio 1 FASE II. Análisis del problema Incluye: Modelo de casos de uso Modelo del dominio Tareas:

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

Operación Microsoft Windows

Operación Microsoft Windows Entornos de red Concepto de red En el nivel más elemental, una red consiste en dos equipos conectados entre sí mediante un cable de forma tal que puedan compartir datos. Todas las redes, no importa lo

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

MARKETING. Clase 15. CONCEPTO DE PRECIO

MARKETING. Clase 15. CONCEPTO DE PRECIO Clase 15. CONCEPTO DE PRECIO Todas las organizaciones lucrativas y muchas no lucrativas deben establecer precios para sus productos o servicios. El precio es la cantidad de dinero que se cobra por producto

Más detalles

Usamos que f( p) = q y que, por tanto, g( q) = g(f( p)) = h( p) para simplificar esta expresión:

Usamos que f( p) = q y que, por tanto, g( q) = g(f( p)) = h( p) para simplificar esta expresión: Univ. de Alcalá de Henares Ingeniería de Telecomunicación Cálculo. Segundo parcial. Curso 2004-2005 Propiedades de las funciones diferenciables. 1. Regla de la cadena Después de la generalización que hemos

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

El módulo tipográfico

El módulo tipográfico contenidos teóricos 4 El módulo tipográfico LA GRILLA Un programa de diseño al servicio del proyecto www.tipografiavenancio.com.ar 1/6 Uno de los temas más polémicos entre los estudiantes y profesionales

Más detalles

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas.

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas. El primer paso en el diseño de una base de datos es la producción del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los

Más detalles

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Jorge Bozo jbozo@inf.ucv.cl Escuela de Ingeniería Informática Universidad Católica de Valparaíso Valparaíso, Chile

Más detalles

Q-flow 3.1: Introducción a Q-flow

Q-flow 3.1: Introducción a Q-flow Q-flow 3.1: Introducción a Q-flow Código del manual: Qf310001ESP Versión: 1.1 Se aplica a: Q-flow 3.1 Última revisión: 13/12/2010 i Q f 3 1 0 0 0 1 E S P v 1. 1 Q - f l o w 3.1 Introducción a Q-flow Urudata

Más detalles

Modelado de información de construccióncapítulo1:

Modelado de información de construccióncapítulo1: Capítulo 1 Modelado de información de construccióncapítulo1: Modelado de información de construcción (BIM) es un flujo de trabajo integrado creado en base a información coordinada y confiable acerca de

Más detalles

www.bvbusiness-school.com

www.bvbusiness-school.com Gráficos de Control de Shewart www.bvbusiness-school.com GRÁFICOS DE CONTROL DE SHEWART Una de las herramientas estadísticas más importantes en el Control Estadístico de Procesos son los Gráficos de Control.

Más detalles

1. PROCESOS DEL PROJECT MANAGEMENT

1. PROCESOS DEL PROJECT MANAGEMENT INDICE 1. PROCESOS DEL PROJECT MANAGEMENT 1.1 Procesos del Proyecto 1.2 Grupos de Proceso 1.3 Interacciones del Proceso 1.4 Adaptación de las interacciones del proceso 2. AREAS DEL CONOCIMIENTO DEL PROJECT

Más detalles

Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows. Módulo 2: Servicios Básicos. DNS

Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows. Módulo 2: Servicios Básicos. DNS Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows Módulo 2: Servicios Básicos. DNS Aulas en red. Aplicaciones y servicios. Windows DNS DNS (Domain Name System) es una abreviatura de Sistema

Más detalles

construcción de programas Prof. Eliana Guzmán U.

construcción de programas Prof. Eliana Guzmán U. Unidad II. Metodología para la construcción de programas Prof. Eliana Guzmán U. Semestre: A-2015 Introducción Resolver un problema con una computadora conduce a la escritura de un programa y a su ejecución.

Más detalles