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.