Modelo Global del Sistema

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.