Modelos del Sistema

41,882 views

Published on

Published in: Education
2 Comments
10 Likes
Statistics
Notes
No Downloads
Views
Total views
41,882
On SlideShare
0
From Embeds
0
Number of Embeds
3,633
Actions
Shares
0
Downloads
711
Comments
2
Likes
10
Embeds 0
No embeds

No notes for slide

Modelos del Sistema

  1. 1. CAPÍTULO 8
  2. 2. contenidos MODELOS DE CONTEXTO MODELOS DE FLUJO DE DATOS MODELOS DE COMPORTAMIENTO MODELOS DE MAQUINAS DE ESTADO MODELOS MODELOS DE DATOSDEL SISTEMA MODELOS DE HERENCIA MODELOS DE OBJETOS AGREGACIÓN DE OBJETOS MODELADO DE MÉTODOS COMPORTAMIENTO DE OBJETOS ESTRUCTURADOS
  3. 3. Una técnica ampliamente usada es documentarla especificación del sistema como un conjuntode modelos del sistema. Estos modelos sonrepresentaciones gráficas que describen losprocesos del negocio, el problema a resolver yel sistema que tiene que ser desarrollado.Debido a las representaciones gráficasusadas, los modelos son a menudo máscomprensibles que las descripciones detalladasen lenguaje natural de los requerimientos delsistema. Ellos constituyen también un puenteimportante entre el proceso de análisis y diseño.
  4. 4. Pueden usarse modelos en el proceso de análisis paracomprender el sistema existente que debe serreemplazado o mejorado, o para especificar el nuevosistema que sea requerido. Pueden desarrollarsediferentes modelos para representar el sistema desdediferentes perspectivas. Por ejemplo:
  5. 5. El aspecto más importante de un modelo del sistema esque omite los detalles.Un modelo del sistema es una abstracción del sistemaque se está estudiando en lugar de una representaciónalternativa de ese sistema.Idealmente, una representación de un sistema deberíamantener toda la información sobre la entidad que se estárepresentando.Una abstracción simplifica y resalta de forma deliberadalas características más relevantes. Por ejemplo, en elcaso improbable de que este libro fuese publicadopor capítulos en un periódico, la presentación en estecaso sería una abstracción de los puntos clave dellibro. Si fuese traducido del inglés al italiano, éstapodría ser una representación alternativa. La
  6. 6. Diferentes tipos de modelos del sistema se basan endistintas aproximaciones de abstracción. Un MODELO DE FLUJO DE DATOS Por el contrario, un (por ejemplo) se centra MODELO DE en el flujo de datos y las ENTIDADES DE transformaciones DATOS Y SUS funcionales sobre esos RELACIONES datos. documentan las Se omiten los detalles estructuras de datos de las estructuras de del sistema en lugar datos. de su funcionalidad.
  7. 7. Ejemplos de tipos de modelos del sistema que podríancrearse durante el proceso de análisis son: 1. Un modelo de flujo de datos • Muestran cómo se procesan los datos en el sistema en diferentes etapas. 2. Un modelo de composición • O agregación muestra cómo las entidades del sistema están compuestas por otras entidades.
  8. 8. 3. Un modelo arquitectónico• Muestran los principales subsistemas que componen un sistema.4. Un modelo de clasificación• Los diagramas de clases herencia de objetos muestran cómo las entidades tienen características comunes.5. Un modelo de estímulo-respuesta.• O diagrama de transición de estados muestra cómo reacciona el sistema a eventos internos y externos.
  9. 9. En una de las primeras etapas de la obtención de requerimientosy del proceso de análisis se deben definir los límites del sistema.Esto comprende trabajar conjuntamente con los stakeholders delsistema para distinguir lo que es el sistema y lo que es el entornodel sistema. Usted debería tomar estas decisiones al inicio delproceso para delimitar los costes del sistema y el tiemponecesario para el análisis.En algunos casos, el límite entre un sistema y su entorno estárelativamente claro. Por ejemplo, en el caso de que un sistemaautomático reemplace a un sistema existente manual ocomputarizado el entorno del nuevo sistema es normalmente elmismo que el entorno del sistema existente. En otros casos, haymás flexibilidad, y usted decide lo que constituye el límite entreel sistema y su entorno durante el proceso de ingeniería derequerimientos.
  10. 10. Por ejemplo, suponga que está desarrollando laespecificación para el sistema de biblioteca LIBSYS.Recuerde que este sistema pretende entregar versioneselectrónicas de material con derechos de autor a losusuarios de computadoras.A continuación los usuarios pueden imprimir copiaspersonales del material. Cuando desarrolla laespecificación para este sistema, usted tiene que decidirsi otros sistemas de bases de datos de bibliotecas talescomo catálogos de bibliotecas están dentro de los límitesdel sistema. Si lo están, entonces puede permitir elacceso al sistema a través de la interfaz de usuario delcatálogo; si no lo están, entonces los usuarios sufrirán laincomodidad de tenerse que mover de un sistema aotro.
  11. 11. La definición de un límite del sistema no es una decisiónarbitraria. Aspectos sociales y organizacionales puedenimplicar que la situación de los límites de un sistema puedanser determinados por factores no técnicos. Por ejemplo, unlímite de un sistema puede situarse de forma que el procesode análisis sólo se pueda llevar a cabo en un lugar; puede serelegido para que un gestor problemático no necesite serconsultado; puede situarse para que el coste del sistema seincremente, y la división del desarrollo del sistema debe, porlo tanto, expandirse al diseño e implementación del sistema.Una vez que se han tomado algunas decisiones sobre loslímites del sistema, parte de la actividad del análisis es ladefinición de ese contexto y de las dependencias que elsistema tiene sobre su entorno. Normalmente, laproducción de un modelo arquitectónico sencillo es elprimer paso en esta actividad.
  12. 12. La Figura 8.1 es un modelo arquitectónico que ilustra la estructuradel sistema de información que incluye una red de cajerosautomáticos.Los modelos arquitectónicos de alto nivel se expresannormalmente como sencillos diagramas de bloques en donde cadasubsistema se representa por un rectángulo con nombre, y laslíneas indican asociaciones entre los subsistemas. Figura 8.1 El contexto de un sistema ATM.
  13. 13. En la Figura 8.1, podemos ver que cada ATM (cajero automático) estáconectado a una base de datos de cuentas, a un sistema de contabilidad dela sucursal, a un sistema de seguridad y a otro de mantenimiento de loscajeros. El sistema también está conectado a una base de datos de usocomún que monitoriza cómo se usa la red de ATMs y también estáconectado a un sistema auxiliar local de una sucursal. Este sistema auxiliarproporciona, servicios tales como copias de seguridad e impresión.Éstos, por lo tanto, no necesitan incluirse en el propio sistema ATM. Figura 8.1 El contexto de un sistema ATM.
  14. 14. Los modelos arquitectónicos describen el entorno de un sistema.Sin embargo, no muestran las relaciones entre otros sistemas delentorno y el sistema que se está especificando. Los sistemasexternos podrían producir o consumir datos del sistema. Podríancompartir datos con el sistema, o podrían ser conectadosdirectamente, conectados a través de una red o no estarconectados. Podrían estar físicamente en el mismo lugar olocalizados en edificios diferentes.Todas estas relaciones podrían afectar a los requerimientos delsistema que se está definiendo y deben tenerse en cuenta.Por lo tanto, los modelos arquitectónicos sencillos normalmentese complementan con otros modelos, tales como modelos deprocesos, que muestran las actividades de los procesos soportadaspor el sistema. Los modelos de flujo de datos (descritos en lasección siguiente) también pueden usarse para mostrar los datosque son transferidos entre el sistema y otros sistemas de suentorno.
  15. 15. La Figura 8.2 ilustra un modelo de proceso de adquisición deequipos de una organización.Esto implica especificar el equipo requerido, buscar y elegir a losproveedores, pedir el equipo, recibir los equipos a su llegada y acontinuación verificarlos.
  16. 16. Cuando especifique el soporte informático para este proceso, ustedtiene que decidir cuáles de esas actividades serán realmenteinformatizadas. El resto de las actividades están fuera de los límitesdel sistema. En la Figura 8.2, la línea discontinua encierra lasactividades que están dentro de los límites del sistema.
  17. 17. Los modelos de comportamiento se utilizan para describir el comportamiento del sistema en su totalidad. Aquí se analizan dos tipos de modelos de comportamiento:Estos modelos pueden usarse de forma separada oconjuntamente, dependiendo del tipo de sistema que se estédesarrollando.
  18. 18. La mayoría de los sistemas de negocio están fundamentalmentedirigidos por los datos. Están controlados por las entradas dedatos al sistema con relativamente poco procesamiento deeventos externos.Un MODELO DE FLUJO DE DATOS puede ser todo lo que senecesite para representar el comportamiento de estos sistemas.Por el contrario, los sistemas de tiempo real a menudo estándirigidos por eventos con un mínimo procesamiento de datos.Un MODELO DE MÁQUINA DE ESTADOS es la forma másefectiva de representar su comportamiento.Otras clases de sistemas pueden estar dirigidas tanto por datoscomo por eventos. En estos casos usted puede desarrollarambos tipos de modelos
  19. 19. Los modelos de flujo de datos son una forma intuitiva de mostrarcómo los datos son procesados por un sistema.A nivel de análisis, deberían usarse para modelar la forma en la quelos datos son procesados en el sistema existente.El uso de modelos de flujo de datos para análisis comenzó a usarseampliamente después de la publicación del libro de DeMarco(DeMarco, 1978) sobre análisis de sistemas estructurados.Estos modelos son una parte intrínseca de los métodos estructuradosque han sido desarrollados a partir de este trabajo.
  20. 20. Los modelos de flujo de datos se utilizan para mostrarcómo fluyen los datos a través de una secuencia de pasosde procesamiento.Por ejemplo, un paso de procesamiento podría ser filtrarregistros duplicados en una base de datos de clientes.Los datos se transforman en cada paso antes de moverse ala siguiente etapa.Estos pasos de procesamiento o transformacionesrepresentan procesos software o funciones cuando losdiagramas de flujo de datos se utilizan para documentarun diseño software.Sin embargo, en un modelo de análisis, el procesamientose puede llevar a cabo por las personas o por lascomputadoras.
  21. 21. Un modelo de flujo de datos, que muestra los pasos que comprende elprocesamiento de un pedido de productos (tales como equipamientoinformático) en una organización, se ilustra en la Figura 8.3. Este modeloparticular describe el procesamiento de datos en la actividadColocar el pedido del equipamiento en el modelo completo del proceso mostradoen la Figura 8.2. El modelo muestra cómo el pedido para los productos fluyedesde un proceso a otro.También muestra los almacenes de datos (Fichero de pedidos y Fichero depresupuesto) que están implicados en este proceso.
  22. 22. Los modelos de flujo de datos son valiosos debido a querealizan un seguimiento y documentan cómo los datosasociados con un proceso particular fluyen a través delsistema, y esto ayuda a los analistas a comprender elproceso.Los diagramas de flujo de datos tienen la ventaja de que, adiferencia de otras notaciones de modelado, son sencillose intuitivos.Normalmente es posible explicarlos a los usuariospotenciales del sistema, quienes pueden entonces participaren la validación del análisis.En principio, el desarrollo de modelos tales como modelosde flujo de datos debería ser un proceso «descendente».En este ejemplo, esto podría implicar que deberíacomenzarse analizando el proceso de adquisición deequipamiento en su totalidad.
  23. 23. A continuación se seguiría con el análisis de subprocesostales como el de solicitud de pedidos. En la práctica, elanálisis nunca se hace así. Se analizan varios niveles al mismotiempo. Los modelos de bajo nivel pueden desarrollarseprimero y después abstraerse para crear un modelo másgeneral.Los modelos de flujo de datos muestran una perspectivafuncional en donde cada transformación representa unúnico proceso o función.Son particularmente útiles durante el análisis derequerimientos ya que pueden usarse para mostrar elprocesamiento desde el principio hasta el final en un sistema.Es decir, muestra la secuencia completa de acciones quetienen lugar a partir de una entrada que se está procesandohasta la correspondiente salida que constituye la respuestadel sistema.
  24. 24. La Figura 8.4 ilustra este uso de los diagramas de flujo de datos. Éste es un diagrama del procesamiento que tiene lugar en el sistema de bomba de insulina introducido en el Capítulo 3.Figura 8.4Diagrama de flujo dedatos de una bombade insulina.
  25. 25. Un modelo de máquina de estados describe cómoresponde un sistema a eventos internos o externos.El modelo de máquina de estados muestra los estadosdel sistema y los eventos que provocan las transicionesde un estado a otro.No muestra el flujo de datos dentro del sistema.Este tipo de modelo se utiliza a menudo para modelarsistemas de tiempo real debido a que estos sistemassuelen estar dirigidos por estímulos procedentes delentorno del sistema.Por ejemplo, el sistema de alarma de tiempo realexplicado en el Capítulo 13 responde a estímulos desensores de movimiento, sensores de apertura depuertas, etcétera.
  26. 26. Los modelos de máquina de estados son una parteintegral de los métodos de diseño de tiempo real talescomo los propuestos por Ward y Mellor. El método deHarel usa una notación denominada diagramas deestado que fue la base para la notación del modelado demáquina de estados en UML.Un modelo de máquina de estados de un sistemasupone que, en cualquier momento, el sistema está enuno de varios estados posibles.Cuando se recibe un estímulo, éste puede disparar unatransición a un estado diferente.Por ejemplo, un sistema de control de una válvula puedemoverse desde un estado «Válvula abierta» a un estado«Válvula cerrada» cuando se reciba una orden (elestímulo) del operador.
  27. 27. Esta aproximación para el modelado de sistemas se ilustra en laFigura 8.5. Este diagrama muestra un modelo de máquina deestados de un sencillo horno microondas equipado con botonespara fijar la potencia y el temporizador y para iniciar el sistema.Los hornos microondas reales son actualmente mucho máscomplejos que el sistema descrito aquí.
  28. 28. Sin embargo, este modelo incluye las características esenciales delsistema. Para simplificar el modelo. Se supone que la secuencia deacciones al usar el microondas es:l. Seleccionar el nivel de potencia (ya sea media o máxima).2. Introducir el tiempo de cocción.3. Pulsar el botón de inicio, y la comida se cocina durante el tiempoestablecido.
  29. 29. Por razones de seguridad, el horno no debería funcionar cuandola puerta esté abierta y, cuando se completa la cocción, suena untimbre. El horno dispone de una pantalla alfanumérica sencillaque se utiliza para visualizar varios mensajes de alerta y deprecaución.
  30. 30. La notación UML utilizada para describir los modelos de máquina deestados está diseñada para modelar el comportamiento de losobjetos. Sin embargo, es una notación de propósito general que sepuede utilizar para cualquier tipo de modelado de máquina deestados. Los rectángulos redondeados en un modelo representan losestados del sistema. Incluyen una breve descripción (a continuaciónde «do») de las acciones realizadas en ese estado. Las flechasetiquetadas representan estímulos que fuerzan transiciones de unestado a otro.
  31. 31. Por lo tanto, en la Figura 8.5, podemos ver que el sistema respondebien inicialmente al botón de potencia máxima o al de potenciamedia. Los usuarios pueden cambiar de idea después de seleccionaruno de éstos y presionar el otro botón. Se fija el tiempo y, si lapuerta está cerrada, se habilita el botón de comienzo. Pulsando estebotón comienza a funcionar el horno y la cocción tiene lugardurante el tiempo especificado.
  32. 32. La notación UML indica la actividad que tiene lugar en unestado. En una especificación detallada del sistema, usted tieneque proporcionar más detalle sobre el estímulo y los estados delsistema (Figura 8.6). Esta información puede mantenerse en undiccionario de datos o enciclopedia (incluida en la Sección 8.3) yque es mantenida por las herramientas CASE utilizadas paracrear el modelo del sistema.El problema con la aproximación de la máquina de estados esque el número de posibles estados crece rápidamente.Por lo tanto, para los modelos de sistemas grandes, es necesariauna cierta estructuración de estos modelos de estados.Una forma de hacer esto es mediante la noción de unsuperestado que encierra a varios estados separados.Este superestado se asemeja a un único estado de un modelode alto nivel, pero se expande a continuación con más detalleen un diagrama distinto.
  33. 33. ESTADO DESCRIPCIÓNEn espero El horno está esperando la entrada. La pantalla muestra la hora actual. La potencia del homo se fija en 300 vatios. La pantalla muestraPotencia media <<Potencia Media>> La potencia del horno se fija en 600 vatios. La pantalla muestraPotencia múima <<Potencia Máxima>> Se fija el tiempo de cocción con el valor de entrada del usuario. LaFijar tiempo pantalla muestra el tiempo de cocción seleccionado y se actualiza en cuanto se fija el tiempo. Se inhabilita el funcionamiento del horno por razones de seguridad. LaInhabilitado luz interior del homo se enciende. La pantalla muestra <<No listo>>. Se habilita el funcionamiento del horno. Se apaga la luz de su interior. LaHabilitado pantalla muestra <<listo para cocinar>>3 El horno está en funcionamiento. La luz interior del horno se enciende. La pantalla muestra la cuenta atrás del temporizador. Cuando finaliza laFuncionamiento cocción, suena un timbre durante 5 segundos. La luz interior se enciende. La pantalla muestra <<Cocción finalizada>> mientras el timbre suena. Figura 8.6EstImulo Descripción Descripción dePotencia media El usuario ha presionado el botón de potencia media. estados y estimulasPotencia múima El usuario ha presionado el botón de potencia máxima. para el hornoTemporizador El usuario ha presionado uno de los botones del temporizador. microondas.Número El usuario ha presionado una teda numérica.Puerta abierta El interruptor de la puerta del horno no está cerrado.Puerta cenada El interruptor de la puerta del horno está cerrado.Iniciar El usuario ha presionado el botón de inicio.Cancelar El usuario ha presionado el botón de cancelar.
  34. 34. Para ilustrar este concepto, considere el estadoFuncionamiento en la Figura 8.5. Éste es unsuperestado que puede expandirse, tal y comose ilustra en la Figura 8.7. figura 8.7 Funcionamiento del horno microondas.
  35. 35. El estado Funcionamiento incluye varios subestados. Muestra que unaoperación comienza con una comprobación de estado, y que si sedescubre cualquier problema, se activa una alarma y la operaciónqueda inhabilitada. La cocción implica poner en marcha el generadorde microondas durante el tiempo especificado; a su terminación, suenaun timbre. Si la puerta se abre durante el funcionamiento, el sistema semueve al estado inhabilitado, tal y como se muestra en la Figura 8.5. figura 8.7 Funcionamiento del horno microondas.
  36. 36. La mayoría de los sistemas software grandes utilizan bases dedatos de información de gran tamaño. En algunos casos, estabase de datos es independiente del sistema software. Enotros, se crea para el sistema que se está desarrollando.Una parte importante del modelado de sistemas es la definiciónde la forma lógica de los datos procesados por el sistema. Éstosse denominan a menudo modelos semánticos de datos.La técnica de modelado de datos más ampliamente usada es elmodelado Entidad-Relación- Atributo (modeladoERA), que muestra las entidades de datos, sus atributosasociados y las relaciones entre estas entidades. Estaaproximación de modelado fue propuesta por primera vez amediados de los años 70 por Chen desde entonces se handesarrollado varias variantes, y todas ellas tienen la misma formabásica.
  37. 37. Los modelos entidad-relación han sido ampliamente usados enel diseño de bases de datos.Los esquemas de bases de datos relacionales derivados deestos modelos se encuentran de manera natural en terceraforma normal, lo cual es una característica deseable. Debido altipado explícito y al reconocimiento de subtipos ysupertipos, también es sencillo implementar estos modelosutilizando bases de datos orientadas a objetos.UML no incluye una notación específica para este modelado debases de datos, ya que asume un proceso de desarrolloorientado a objetos y modela los datos utilizando objetos y susrelaciones. Sin embargo, se puede usar UML para representarun modelo semántico de datos.Se puede pensaren las entidades de un modelo ERA (Entidad-Relación- Atributo) como clases de objetos simplificadas (notienen operaciones), los atributos como atributos de la clase ylas denominadas asociaciones entre clases como relaciones.
  38. 38. La Figura 8.8 es un ejemplo de un modelo de datos que es parte del sistema debiblioteca LIBSYS introducido en capítulos anteriores. Recuerde que LIBSYS sediseña para entregar copias de artículos con derechos de autor que han sidopublicados en revistas y periódicos y para registrar el pago de estos artículos. Porlo tanto, el modelo de datos debe incluir información sobre el artículo, el poseedorde los derechos de autor y el comprador del artículo.Aquí hemos supuesto que estos pagos para los artículos no se hacen directamentesino a través de agencias nacionales de derechos de autor. Figura 8.8 Modelo semántico de datos para el sistema L1BSYS.
  39. 39. La Figura 8.8 muestra que un Articulo tiene atributos que representan eltítulo, los autores, el nombre del fichero PDF del artículo y el honorario a pagar.Éste se enlaza con Fuente, en donde fue publicado el artículo, y con la Agenciade derechos de autor del país de publicación. Ambos, Agencia de derechos deautor y Fuente, se enlazan con País. El país de publicación es importante debidoa que las leyes de derechos de autor varían de un país a otro. El diagramatambién muestra que los Compradores emiten Órdenes de compra de Artículos.Figura 8.8Modelo semánticode datos para elsistema L1BSYS.
  40. 40. Al igual que todos los modelos gráficos, a los modelos de datos lesfaltan detalles, y usted debería mantener descripciones másdetalladas de las entidades, relaciones y atributos incluidas en elmodelo. Usted puede reunir estas descripciones más detalladas enun repositorio o diccionario de datos. Los diccionarios de datosgeneralmente son útiles cuando desarrollamos modelos de sistemasy pueden utilizarse para gestionar toda la información de todos lostipos de modelos de sistemas.Un diccionario de datos es, de forma simple, una lista de nombresordenada alfabéticamente incluida en los modelos del sistema. Eldiccionario debería incluir, además del nombre, una descripciónasociada de dicha entidad con nombre y, si el nombre representaun objeto compuesto, una descripción de la composición. Se puedeincluir otra información, como la fecha de creación, el creador y larepresentación de la entidad dependiendo del tipo de modelo quese esté desarrollando.
  41. 41. Las ventajas de usar un diccionario de datos son las siguientes: l. Es un mecanismo para la 2. Sirve como un almacén de gestión de nombres. información de la organización. Muchas personas pueden tener que inventar nombres A medida que el sistema para las entidades y relaciones se desarrolla, la cuando están desarrollando información que enlaza un modelo de un sistema el análisis, diseño, grande estos nombres implementación y deberían ser usados de forma evolución se añade al consistente y no deberían diccionario de datos, entrar en conflicto. El para que toda la software del diccionario de datos puede comprobar la información sobre una unicidad de los nombres entidad esté en un cuando sea necesario y avisar mismo lugar. a los analistas de requerimientos de las duplicaciones de nombres.
  42. 42. Las entradas del diccionario de datos mostradas en la Figura 8.9definen los nombres en el modelo semántico de datos para LIBSYS(Figura 8.8). Se ha simplificado la presentación de este ejemploobviando algunos nombres y reduciendo la información asociada. Detalle del articulo publicado que Artículo puede pedirse por las personas que Entidad 30.12.2002 usen LIBSYS Los nombres de los Autores del Autores articulo Atribulo que pueden Atributo 30.12.2002 compartir los honorarios La persona u organización que emite Comprador Entidad 29.12.2002 emite la orden de copia del articulo Una relación 1:1 entre Artículo y la Honorarios a Agencia de derechos de autor a quienFigura 8.9 Relación 31.12.2002 pagar a se deberla abonar el honorario deEjemplos de derechos de autorentradasde diccionario La dirección del comprador. Esta sede datos. Dirección utiliza para cualquier información que atributo 30.12.2002 (Compredor) se requiera que se requiera sobre la factura en papel
  43. 43. Todos los nombres del sistema, tanto si sonnombres de entidades, relaciones, atributos oservicios, deberían introducirse en el diccionario.El software se utiliza normalmente paracrear, mantener y consultar el diccionario. Estesoftware debería integrarse con otrasherramientas para que la creación del diccionariose automatice parcialmente. Por ejemplo, lasherramientas CASE que soportan el modelado delsistema incluyen soporte para el diccionario dedatos e introducen los nombres en el diccionariocuando se utilizan por primera vez en el modelo.
  44. 44. Una aproximación orientada a objetos para el proceso dedesarrollo del software en su totalidad se usa actualmente deforma generalizada, en particular para el desarrollo de sistemasinteractivos. Esto significa expresar los requerimientos de lossistemas utilizando un modelo de objetos, diseñar utilizandoobjetos y desarrollar el sistema en un lenguaje de programaciónorientado a objetos, como por ejemplo Java o C++.Los modelos de objetos que usted desarrolla durante el análisisde requerimientos pueden utilizarse para representar tantolos datos del sistema como su procesamiento. A esterespecto, dichos modelos combinan algunos de los usos de losmodelos de flujo de datos y los modelos semánticos dedatos.Los modelos de objetos también son útiles para mostrar cómo seclasifican las entidades en el sistema y se componen de otras
  45. 45. Para algunas clases del sistema. Los modelos de objetos son formasnaturales de reflejar las entidades del mundo real que son manipuladaspor el sistema. Esto es particularmente cierto cuando el sistema procesainformación sobre entidades tangibles, tales como coches, aviones olibros, que tienen atributos claramente identificables. Entidades másabstractas, y de más alto nivel, tales como el concepto de unabiblioteca, un sistema de registros médicos o un procesador detexto, son más difíciles de modelar como clases de objetos. Éstos notienen necesariamente una interfaz sencilla consistente en atributosindependientes y operaciones.El desarrollo de modelos de objetos durante el análisis derequerimientos normalmente simplifica la transición entre el diseñoorientado a objetos y la programación. Sin embargo, se observa que losusuarios de un sistema a menudo buscan modelos de objetos nonaturales y difíciles de entender. Ellos pueden preferir adoptar unpunto de vista más funcional y de proceso de datos. Por lo tanto, aveces es útil complementar el modelo de objetos con modelos deflujos de datos que muestren el procesamiento de datos en el sistemadesde el principio hasta el final.
  46. 46. Una clase de objetos es una abstracción sobre un conjunto deobjetos que identifica atributos comunes (como en un modelosemántico de datos) y los servicios u operaciones que sonproporcionados por cada objeto. Los objetos son entidadesejecutables que tienen atributos y servicios de la clase de objetos.Los objetos son instanciaciones de la clase de objetos, y puedencrearse muchos objetos a partir de una clase. Generalmente, losmodelos desarrollados utilizando análisis se centran en las clasesde objetos y en sus relaciones.En el análisis de requerimientos orientado a objetos, deberíanmodelarse entidades del mundo real utilizando clases de objetos.No deberían incluirse detalles de los objetos individuales(instanciaciones de la clase) en el sistema. Se pueden creardiferentes tipos de modelos de objetos, mostrando cómo las clasesde objeto se relacionan unas con otras, cómo los objetos sonagregados para formar otros objetos, cómo los objetos interactúancon otros objetos, etcétera. Cada uno de éstos presenta unainformación distinta sobre el sistema que se está especificando.
  47. 47. El proceso de análisis para identificar los objetos y las clases deobjetos se reconoce como una de las áreas más difíciles deldesarrollo orientado a objetos. La identificación de objetos esbásicamente la misma para el análisis y para el diseño. Puedenutilizarse los métodos de identificación de objetos tratados en elCapítulo 14, que analiza el diseño orientado a objetos.Aquí se tratan algunos de los modelos de objetos que podríangenerarse durante el proceso de análisis.En los años 90 se propusieron varios métodos de análisis orientadosa objetos Estos métodos tienen mucho en común, y tres de estosdesarrolladores (Booch, Rumbaugh y Jacobsen) decidieron integrarsus aproximaciones para producir un método unificado. El LenguajeUnificado de Modelado (UML) utilizado en este método unificadose ha convertido en un estándar para el modelado de objetos. UMLincluye notaciones para diferentes tipos de modelos de sistemas.Nosotros ya hemos visto los modelos de casos de uso y losdiagramas de secuencia en capítulos anteriores y los modelos demáquinas de estados al principio de este capítulo.
  48. 48. Una clase de objetos en UML, como seha ilustrado en los ejemplos de laFigura 8.10, se representa como unrectángulo orientado verticalmentecon tres secciones: Figura 8.10 Parte de una jerarquía de clases para una biblioteca.
  49. 49. l. El nombre de la clase de objetos está en la sección superior.2. Los atributos de la clase están en la sección intermedia.3. Las operaciones asociadas con la clase de objetos están en la sección inferior del rectángulo. Figura 8.10 Parte de una jerarquía de clases para una biblioteca.
  50. 50. Debido a la limitación de espacio paraincluir todo sobre UML, aquí sólo se tratanmodelos de objetos que muestrancómo los objetos pueden clasificarse ypueden heredar atributos y operaciones deotros objetos.modelos de agregación que muestrancómo están compuestos los objetos, ymodelos de comportamientosencillos, que muestran las interaccionesentre los objetos.
  51. 51. El modelado orientado a objetos implica laidentificación de clases de objetos que son importantesen el dominio que se está estudiando. Estos objetos seorganizan a continuación en una taxonomía.Una taxonomía es un esquema de clasificación quemuestra cómo una clase de objetos está relacionadacon otras clases a través de atributos y servicioscomunes.Para mostrar esta taxonomía, las clases se organizan enuna jerarquía de herencia con las clases de objetos másgenerales al principio de la jerarquía. Los objetos másespecializados heredan sus atributos y servicios. Estosobjetos especializados pueden tener sus propiosatributos y servicios.
  52. 52. La Figura 8.10 ilustra parte de unajerarquía de clases simplificada para unmodelo de biblioteca. Esta jerarquíaproporciona información sobre loselementos almacenados en labiblioteca. La biblioteca comprendevarios elementos, tales como libros,música, grabaciones de películas,revistas y periódicos.Figura 8.10 Partede una jerarquíade clases para unabiblioteca.
  53. 53. En la Figura 8.10, el elemento másgeneral está en la raíz del árbol y tieneun conjunto de atributos y servicios queson comunes a todos los elementos dela biblioteca. Éstos son heredados porlas clases Elemento publicado yElemento registrado, que añaden suspropios atributos que son heredados acontinuación por elementos de nivelesinferiores. Figura 8.10 Parte de una jerarquía de clases para una biblioteca.
  54. 54. La Figura 8.11 es un ejemplo de otra jerarquía de herencia quepodría ser parte del modelo de biblioteca. En este caso, semuestran los usuarios de una biblioteca.Hay dos clases de usuarios: aquellos a los que se les permite pedirprestados libros, y aquellos que sólo pueden leer los libros en labiblioteca sin llevárselos. Figura 8.11 Jerarquía de clases de usuarios.
  55. 55. En la notación UML, la herencia se muestra «hacia arriba» enlugar de «hacia abajo» como en otras notaciones orientadas aobjetos o en lenguajes tales como Java, en donde las subclasesheredan de las superclases. Es decir, la punta de la flecha(mostrada como un triángulo) apunta desde las clases queheredan sus atributos y operaciones hasta su superclase.En lugar de utilizar el término herencia. UML habla derelación de generalización.El diseño de jerarquías de clases no es fácil, ya que el analistanecesita comprender con detalle el dominio en el que elsistema será implantado. Como ejemplo de los problemassutiles que surgen en la práctica, considere la jerarquía deelementos de la biblioteca. Podría parecer que el atributoTítulo podría situarse como el elemento más general, y acontinuación ser heredado por elementos de nivelesinferiores.
  56. 56. Sin embargo, si bien cada elemento en una bibliotecadebe tener algún tipo de identificador o número deregistro, esto no significa que todos los elementosdeban tener un título. Por ejemplo, una bibliotecapuede almacenar ciertos elementos personales de unpolítico retirado. Muchos de estos elementos, talescomo cartas, pueden no tener un título de formaexplícita. Éstos serán clasificados utilizando algunaotra clase (no mostrada aquí) que tiene un conjuntodiferente de atributos.
  57. 57. Las Figuras 8.10 y 8.11 muestran jerarquías de herencia de clases en las que cada clase de objetos hereda sus atributos y operaciones de una única clase padre. También pueden construirse modelos de herencia en los que una clase tiene varios padres. Sus atributos y servicios son una conjunción de los heredados de cada superclase.Figura 8.10 Partede una jerarquíade clases para unabiblioteca. Figura 8.11 Jerarquía de clases de usuarios.
  58. 58. La Figura 8.12 muestra un ejemplo de modelo de herenciamúltiple que también puede ser parte del modelo de biblioteca. Figura 8.12 Herencia múltiple.
  59. 59. El problema principal con la herencia múltiple esel diseño de un grafo de herencia en donde losobjetos no heredan atributos innecesarios. Entreotros problemas se incluye la dificultad dereorganizar el grafo de herencia cuando serequieren cambios y resolver conflictos denombres cuando dos o más superclases tienen elmismo nombre pero diferentes significados.A nivel de modelado de sistemas, tales conflictosson relativamente fáciles de resolver alterandomanualmente el modelo de objetos. Esto puedeocasionar más problemas en la programaciónorientada a objetos.
  60. 60. Así como se adquieren atributos y servicios a través de una relaciónde herencia con otros objetos, algunos objetos son agrupacionesde otros objetos. Es decir, un objeto es un agregado de unconjunto de otros objetos. Las clases que representan a estosobjetos pueden modelarse utilizando un modelo de agregación, taly como se muestra en la Figura 8.13.Figura 8.13 Objetoagregado querepresenta un curso.
  61. 61. En este ejemplo, se ha modelado un elemento de biblioteca, consistente en un paquete de estudio para un curso universitario. El paquete de estudio comprende apuntes de clase, ejercicios, soluciones ejemplo, copias de las transparencias usadas en las clases y cintas de vídeo.Figura 8.13 Objetoagregado querepresenta un curso.
  62. 62. La notación UML para la agregación consiste en representar la composición incluyendo una figura de diamante colocada sobre el elemento fuente del enlace. Por lo tanto, la Figura 8.13 puede leerse como "Un paquete de estudio está compuesto por uno o varios elementos asignados, paquetes de transparencias OHP, apuntes y cintas de vídeo».Figura 8.13 Objetoagregado querepresenta un curso.
  63. 63. Para modelar el comportamiento de los objetos, se tiene quemostrar cómo se utilizan las operaciones proporcionadas por losobjetos. En UML, se modelan los comportamientos utilizandoescenarios que son representados como casos de uso UML(estudiados en el Capítulo 7).Una forma de modelar los comportamientos es utilizardiagramas de secuencia UML que muestran la secuenciade acciones implicadas en un caso de uso. Además de losdiagramas de secuencia, UML también incluye diagramas decolaboración que muestran la secuencia de mensajesintercambiados por los objetos. Estos diagramas son similares alos diagramas de secuencia, por lo que no se tratan aquí.
  64. 64. Se puede ver cómo se pueden utilizar los diagramas de secuencia para modelar el comportamiento en la Figura 8.14. que expande un caso de uso del sistema LlBSYS en el que los usuarios solicitan préstamos a la biblioteca en formato electrónico.Figura 8.14Expediciónde elementos enformato electrónico.
  65. 65. Por ejemplo, imagine una situación en la que los paquetes de estudio mostrados en la Figura 8.13 podrían mantenerse en formato electrónico y descargarse a la computadora del estudiante.Figura 8.13 Objetoagregado querepresenta un curso.
  66. 66. En un diagrama desecuencia, los objetos y losactores se alinean en la partesuperior del diagrama.Las flechas etiquetadasindican las operaciones; lasecuencia de operaciones selleva a cabo desde arribahacia abajo enviado al usuariode la biblioteca.
  67. 67. En este escenario, el usuario dela biblioteca accede al catálogopara ver si el elementosolicitado está disponible enformato electrónico; si loestá, el usuario solicita dichoelemento. Por razones dederechos de autor, se debeasignar una licencia al elementopara que exista una transacciónentre el elemento y elusuario, que debe aceptardicha licencia. El elementosolicitado se envía a un objetoservidor de red para sucompresión antes de serenviado al usuario de la
  68. 68. Se puede encontrar otro ejemplo de un diagrama de secuencia que expande un caso de uso de LIBSYS en la Figura 7.8, que muestra la secuencia de actividades implicadas en la impresión de un artículo.Figur.7.8Interaccionesdel sistema para laimpresiónde artículos.
  69. 69. Un método estructurado es una forma sistemática deelaborar modelos de un sistema existente o de unsistema que tiene que ser construido. Fuerondesarrollados por primera vez en la década de los 70para soportar el análisis y el diseño del software yevolucionaron en las décadas de los 80 y de los 90 parasoportar el desarrollo orientado a objetos . Estosmétodos orientados a objetos se unieron con lapropuesta UML como lenguaje de modelado estándar yel Proceso Unificado, y más tarde con el ProcesoUnificado de Rational como un método asociadoestructurado. Budgen resume y compara varios de estosmétodos estructurados.
  70. 70. Los métodos estructurados proporcionan un marcopara el modelado detallado de sistemas como partede la elicitación y análisis de requerimientos. Lamayoría de métodos estructurados tienen su propioconjunto preferido de modelos de sistemas.Normalmente definen un proceso que puede utilizarsepara derivar estos modelos y un conjunto de reglas yguías que aplican a dichos modelos. Se genera unadocumentación estándar para el sistema.Normalmente se encuentran disponibles herramientasCASE que soportan el uso de métodos. Estasherramientas soportan la edición de modelos ygeneración de código y documentación, yproporcionan algunas capacidades para comprobar losmodelos.
  71. 71. Los métodos estructurados han sido aplicados con éxito en muchosproyectos grandes.Pueden suponer reducciones significativas de coste debido a queutilizan notaciones estándar y aseguran que se produce unadocumentación de diseño estándar. Sin embargo, los métodosestructurados tienen una serie de inconvenientes:1. No proporcionan un soporte efectivo para la comprensión o el modelado de requerimientos del sistema no funcionales.2. No discriminan en tanto que normalmente no incluyen guías que ayuden a los usuarios a decidir si un método es adecuado para un problema concreto. Tampoco incluyen normalmente consejos sobre cómo pueden adaptarse para su uso en un entorno particular.3. A menudo generan demasiada documentación. La esencia de los requerimientos del sistema puede quedar oculta por el volumen de detalle que se incluye.4. Los modelos producidos son muy detallados, y los usuarios a menudo los encuentran difíciles de entender. Estos usuarios, por lo tanto, no pueden comprobar el realismo de estos modelos.
  72. 72. En la práctica, sin embargo, los ingenieros de requerimientos y losdiseñadores no se restringen a los modelos propuestos por unmétodo determinado. Por ejemplo, los métodos orientados aobjetos no sugieren normalmente que los modelos de flujos dedatos deban desarrollarse.Sin embargo, según mi experiencia, dichos modelos son a menudoútiles como parte del proceso de análisis de requerimientos debidoa que pueden presentar un panorama general del procesamientoen el sistema desde el principio hasta el final.También pueden contribuir directamente a la identificación de losobjetos (los datos que fluyen) y la identificación de las operacionessobre esos objetos (las transformaciones).Las herramientas CASE de análisis y diseño soportan lacreación, edición y análisis de las notaciones gráficas utilizadas enlos métodos estructurados. La Figura 8.15 muestra loscomponentes que pueden ser incluidos en los entornos quesoportan métodos.
  73. 73. Las herramientas que soportan métodos completos, tal y comose ilustra en la Figura 8.15, normalmente incluyen: 1. EDITORES DE DIAGRAMAS utilizados para crear modelos de objetos, modelos de datos, modelos de comportamiento, etcétera. Estos editores no son simplemente herramientas de dibujo puesto que identifican los tipos de entidades en el diagrama. Captan la información sobre estas entidades y guardan esta información en el repositorio central.Figura 8.15 Loscomponentes deuna herramientaCASE para el soportede métodosestructurados.
  74. 74. Las herramientas que soportan métodos completos, tal y comose ilustra en la Figura 8.15, normalmente incluyen:2. HERRAMIENTAS DE ANÁLISIS Y COMPROBACIÓN DE DISEÑOS que procesan el diseño e informan sobre errores y anomalías. Pueden integrarse con el sistema de edición para que los errores del usuario sean detectados en etapas tempranas del proceso de desarrollo.Figura 8.15 Loscomponentes deuna herramientaCASE para el soportede métodosestructurados.
  75. 75. Las herramientas que soportan métodos completos, tal y comose ilustra en la Figura 8.15, normalmente incluyen: 3. LENGUAJES DE CONSULTA DEL REPOSITORIO que permite al diseñador encontrar diseños e información asociada a los diseños en el repositorio.Figura 8.15 Loscomponentes deuna herramientaCASE para el soportede métodosestructurados.
  76. 76. Las herramientas que soportan métodos completos, tal y comose ilustra en la Figura 8.15, normalmente incluyen: 4. UN DICCIONARIO DE DATOS que mantiene información sobre las entidades utilizadas en el diseño de un sistema.Figura 8.15 Loscomponentes deuna herramientaCASE para el soportede métodosestructurados.
  77. 77. Las herramientas que soportan métodos completos, tal y comose ilustra en la Figura 8.15, normalmente incluyen:5. HERRAMIENTAS DE GENERACIÓN Y DEFINICIÓN DE INFORMES que obtienen información del almacén central y generan automáticamente la documentación del sistema.Figura 8.15 Loscomponentes deuna herramientaCASE para el soportede métodosestructurados.
  78. 78. Las herramientas que soportan métodos completos, tal y comose ilustra en la Figura 8.15, normalmente incluyen: 6. HERRAMIENTAS DE DEFINICIÓN DE FORMULARIOS que permiten especificar los formatos de pantallas y de documentos.Figura 8.15 Loscomponentes deuna herramientaCASE para el soportede métodosestructurados.
  79. 79. Las herramientas que soportan métodos completos, tal y comose ilustra en la Figura 8.15, normalmente incluyen: 7. FACILIDADES PARA IMPORTAR/EXPORTAR que permiten el intercambio de información desde el repositorio central con otras herramientas de desarrollo.Figura 8.15 Loscomponentes deuna herramientaCASE para el soportede métodosestructurados.
  80. 80. Las herramientas que soportan métodos completos, tal y comose ilustra en la Figura 8.15, normalmente incluyen: 8. GENERADORES DE CÓDIGO que generan código o esqueletos de código de forma automática a partir del diseño capturado en el almacén central.Figura 8.15 Loscomponentes deuna herramientaCASE para el soportede métodosestructurados.
  81. 81. La mayoría de los conjuntos de herramientas CASEcompletos permiten al usuario generar un programa oun fragmento de un programa a partir de la informaciónproporcionada en el modelo del sistema. Lasherramientas CASE a menudo soportan diferenteslenguajes para que el usuario pueda generar unprograma en C. C++ o Java a panir del mismo modelo dediseño. Debido a que los modelos excluyen detalles debajo nivel, el generador de código en un banco detrabajo de diseño no puede normalmente generar elsistema completo.Normalmente es necesaria alguna codificación manualpara añadir detalles al código generado.
  82. 82. Un modelo es una vista abstracta de un sistemaque prescinde de algunos detalles del mismo.Pueden desarrollarse modelos del sistemacomplementarlos para presentar otra Informaciónsobre dicho sistema.Los modelos de contexto muestran como el sistema que seestá modelando se ubica en un entorno con otros sistemasy procesos. Definen los limites del sistema. Los modelosarquitectónicos, los modelos de procesos y modelos deflujos de datos pueden utilizarse como modelos decontexto.
  83. 83. Los diagramas de flujo de datos pueden utilizarsepara modelar el procesamiento de los datosllevado acabo por un sistema. El sistema semodela como un conjunto de transformacionesde datos con funciones que actúan sobre losdatos.Los modelos de maquina de estados se utilizanpara modelar el comportamiento del sistema enrespuesta a eventos Internos o externos.
  84. 84. Los modelos semánticos de datos describen laestructura lógica de los datos importados yexportados por el sistema. Estos modelosmuestran las entidades del sistema, susatributos y las relaciones en las que Intervienen.Los modelos de objetos describen las entidadeslógicas del sistema y su clasificación y agregación.Combinan un modelo de datos con un modelo deprocesamiento. Posibles modelos de objetos quepueden desarrollarse Incluyen modelos deherencia, modelos de agregadón y modelos decomportamiento..
  85. 85. Los modelos de secuencia que muestran lasinteracciones entre actores y objetos en unsistema se utilizan para modelar elcomportamiento dinámicoLos métodos estructurados proporcionan unmarco para soportar el desarrollo de modelosdel sistema. Los métodos estructuradosnormalmente son soportados de formaextensiva por herramientas CASE, incluyendo laedición de modelos y la comparación ygeneración de código.

×