Conceptos y propsito del modelo del modelo global del sistema.
El modelo global del sistema posibilita tener una visin general del modelo de estructura de objetos del sistema, asistiendo en el manejo de la complejidad. Las principales razones para utilizar un modelo global del sistema son: Posibilita el particionamiento de una tarea de anlisis o desarrollo. Para grandes sistemas, subsistemas pueden ser asignados a diferentes equipos o sub-proyectos. Puede utilizarse para definir unidades de entrega, PE: unidades funcionales (mdulos) que deban entregarse al usuario en sucesivas fechas de liberacin, o componentes de producto. Puede utilizarse para definir unidades distribubles. Puede utilizarse para validar el diseo de un sistema y asegurar que est bien diseado para soportar el cambio. Incluye un diagrama (el diagrama de visin general del sistema) que puede utilizarse para producir una visin general de un modelo del anlisis o de un subsistema, asistiendo con la presentacin de un modelo o subsistema a un nivel de visin general. Una caracterstica importante del modelo global es que permite el modelado de interfaces entre subsistemas. Esto se logra modelando los servicios que un subsistema ofrece para ser utilizados por otro subsistema. Conceptos El modelo global implica la subdivisin del espacio de problema en componentes. En un enfoque de desarrollo orientado a objetos, esto se alcanza agrupando clases de objetos. El modelado orientado a objetos difiere aqu de las tcnicas estructuradas, en que en estas, los subsistemas usualmente agrupan funciones, no objetos. Las secuencias de transacciones no necesariamente residen en un nico subsistema. Pueden requerir el soporte de objetos pertenecientes a ms de un subsistema o componente. El espacio del problema y sus componentes. Durante la etapa de anlisis del negocio, el espacio del problema es el dominio del negocio, y podemos optar por dividir dicho dominio en reas sujetos. Cada rea sujeto contiene clases de objetos semnticamente relacionadas unas a otras, vinculadas con el mismo sujeto. Durante el desarrollo, el espacio del problema es el sistema o subsistema que se construye. Esto tambin puede ser subdividido en sub- modelos o subsistemas. Los sub-modelos son utilizados principalmente con propsitos de presentacin. Los subsistemas son definidos por razones tcnicas como ser: definicin de unidades de distribucin, y definicin de mdulos, importante para validar y preservar la mantenibilidad del sistema. Otro uso del particionamiento es la subdivisin arquitectural, la cual es particularmente importante durante el diseo fsico. Se recomienda la divisin de todo sistema en seis subsistemas arquitecturales: El componente dominio de problema: es el ms importante y en el cual nos concentramos durante el anlisis de requerimientos y el diseo lgico. El componente de Interfaz humana: introducido en el diseo lgico. El componente de interfaz externa: introducido durante el diseo lgico. El componente de administracin de datos: introducido durante el diseo fsico. El componente de administracin de tareas: introducido durante el diseo fsico. El componente de servicio de utilidades: introducido durante el diseo fsico.
Definicin del alcance de un subsistema Bsicamente, las clases de objetos que tienen un alto grado de interdependencia y sirven a un propsito comn, deben asignarse al mismo subsistema. Usualmente, jerarquas de herencia y agregacin, deben ser asignadas completamente a un subsistema. Debe notarse que si existen objetos que son requeridos por diferentes subsistemas, entonces dichos objetos no deben asignarse a un subsistema. etapa / diseo logico diseo fisico componentes dominio de problema x x Interfaz humana x interfaz externa x administracin de datos x administracin de tareas x servicio de utilidades x analisis de requerimientos Servicios Un subsistema provee sus servicios va una interface, la cual es un conjunto de operaciones que los clientes de un subsistema pueden utilizar. Son tiles estas operaciones en servicios. Cada servicio agrupa operaciones relacionadas que tienen un propsito comn. Los servicios provistos por un subsistema a otro, o a actores, pueden identificarse determinando que comunicaciones son posibles entre subsistemas, y agrupar estas en servicios. Es conveniente que esto se realice durante el diseo lgico, cuando las operaciones han sido definidas. Los subsistemas pueden vincularse en relaciones cliente-servidor o partner to partner (compaero a compaero). En este ltimo caso, un subsistema puede ser cliente y servidor a la vez. Particiones verticales y horizontales Un sistema puede ser particionado horizontalmente (en capas) o verticalmente. Las particiones verticales son usadas para subdividir la funcionalidad de la aplicacin, mientras que las particiones horizontales son particularmente tiles para aislar las aplicaciones de capas de software de menor nivel como ser sistemas operativos, bases de datos o hardware. Este enfoque por capas (layers) asegura la portabilidad de una aplicacin. En el siguiente ejemplo el dominio de problema se divide en cuatro particiones verticales. El componente de administracin de datos es una particin horizontal, la cual existe para aislar a la aplicacin del software de base de datos utilizada.
Diagrama de Modelo Global del Sistema Componentes del diagrama Actor: personas que interactan con el subsistema o interfaces con otros subsistemas.
Subsistema de reportes Subsistema de seminario Subsistema de registracin Subsistema de memos Componente de Administracin de Datos Bordes del sistema: se representan con un rectngulo en lnea gruesa. Los actores se dibujan fuera del rectngulo, y los subsistemas dentro.
Subsistema: se representan con un rectngulo redondeado.
Servicios: se representan como semicrculos dentro del rectngulo correspondiente al subsistema. Actor usando un servicio: se representa como una flecha que vincula al actor con el servicio que usa. Obs. Uso de Clases de Objetos para encapsular subsistemas. Es posible encapsular la funcionalidad de un sistema utilizando object wrapper (envoltura). Esto puede ser muy til para permitir la utilizacin de un sistema no orientado a objetos desde un sistema orientado a objetos. Esto se realiza definiendo un objeto interface el cual puede llamarse para invocar las funciones provistas por el sistema encapsulado. Solo dicho objeto interface necesita conocer el funcionamiento interno del sistema que encapsula. Tambin es posible utilizar una clase de objetos para encapsular el acceso a un sistema orientado a objetos. Si no se utiliza esto, todos los mensajes provenientes del exterior del subsistema, deben dirigirse directamente a la clase de objetos correspondiente dentro del mismo, lo que implica que los actores que necesiten utilizar la funcionalidad del subsistema, deban conocer la estructura interna del mismo. Utilizando un objeto interfaz, se oculta la complejidad interna del subsistema y es posible definir una interfaz sencilla para los clientes externos.