Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Actividad

Ingeniería en Sistemas de Información

Diseño de Sistemas(3K1)

Contenidos de la Unidad 4Diseño Orientado a

Objetos II4. Diseño orientado a Objetos II

A. Diagrama de Clases. Craig Larman., Cap. 21

a. Generalización.

a. Agregación.

a. Composición.

B. Visibilidad entre Objetos Craig Larman., Cap. 20

C. Paquetes, Estratos y Particiones Craig Larman., Cap. 22

D. Diagrama de actividad. Craig Larman., Cap. 33

E. Diagrama de Transición de estado. Craig Larman., Cap. 33

VisibilidadVisibilidad

Craig Larman, Cap. 20Craig Larman, Cap. 20

Ingeniería en Sistemas de Información

Es la capacidad de un objeto para ver a otro o hacer referencia a él.

Los Diagramas de Colaboración (para cada Evento del Sistema) describen gráficamente los mensajes entre Objetos.

Para que un Objeto Emisor envíe un mensaje a un Objeto Receptor, éste tiene que ser VISIBLE a aquél.

VisibilidadIntroducción

Visibilidad

En el ejemplo siguiente, el mensaje “Captura” enviado por CAJA a Venta significa que Venta es, de alguna manera, VISIBLE a CAJA.

CAJA

IntroducirProducto()

Venta

fechaestaTerminada: Booleanohora

IntroducirProducto()

Captura

1 1

Cuando se construye un Diseño de Objetos que interactúan, debemos asegurarnos de que exista la VISIBILIDAD necesaria; ya que, de otro modo, no se podrá dar soporte a la interacción de los mensajes.

Hay 4 formas comunes de conseguir visibilidad del Objeto A hacia el Objeto B:

1)Visibilidad de Atributos: B es un atributo de A.2)Visibilidad de Parámetros: B es un parámetro de un Método de A.3)Visibilidad Declarada Localmente: Se declara que B es un objeto

local en un método de A.4)Visibilidad Global: En alguna forma, B es visible globalmente.

Visibilidad

“Para que un Objeto A envíe un mensaje a un Objeto B, éste debe ser visible a aquél”.

Por ejemplo, para preparar un Diagrama de Colaboración, donde se requiera que el objeto CAJA envíe un mensaje al objeto Venta; CAJA debe tener VISIBILIDAD hacia Venta.

Una solución usual suele consistir en conservar, como atributo de CAJA, una referencia a Venta (Visibilidad de ATRIBUTO).

Visibilidad

Existe Visibilidad de Atributos de A hacia B, cuando B es un ATRIBUTO de A.

Se trata de una VISIBILIDAD relativamente permanente, ya que subsiste mientras existan A y B.

Es una forma muy común de visibilidad en los sistemas orientados a objetos.

Visibilidad de Atributos

Existe Visibilidad de Parámetros de A hacia B, cuando B se transmite como un parámetro a un Método de A.

Se trata de una Visibilidad relativamente TEMPORAL; pues subsiste sólo dentro del ámbito del Método.

Después de la Visibilidad de Atributo, es la forma más común de Visibilidad, en los sistemas orientados a objetos.

Por ejemplo, si enviamos desde CAJA el mensaje “hacerlineadeproducto” a una instancia de Venta, podemos mandar como parámetro, dentro de ese mensaje, una instancia de EspecificaciondeProducto.

Entonces, dentro del ámbito del método “hacerlineadeproducto”, Venta tiene Visibilidad de Parámetro hacia EspecificaciondeProducto.

Visibilidad de Parámetros

Visibilidad de Parámetros

Existe Visibilidad Declarada Localmente de A hacia B cuando se declara que B es un objeto local, dentro de un método de A.

Se trata de una Visibilidad relativamente TEMPORAL, pues persiste únicamente dentro del ámbito del Método.

Después de la Visibilidad de Parámetros, es la TERCERA más utilizada, en los sistemas orientados a objetos.

Visibilidad declarada localmente

Existen dos medios habituales para lograr esta forma de Visibilidad:

1)Crear una nueva Instancia Local y asignarle una Variable Local.

2)Asignar a una Variable Local el Objeto devuelto, proveniente de la llamada el Método.



Existe Visibilidad Global de A hacia B, cuando B es GLOBAL para A. Se trata de una Visibilidad relativamente PERMANENTE; pues persiste mientras

existan A y B. Es la Visibilidad MENOS FRECUENTE en los sistemas orientados a objetos. Es la forma más obvia (aunque menos conveniente) de alcanzar la Visibilidad

Global. Consiste en asignar una instancia a una Variable Global.

Visibilidad global

Visibilidad


Objetos II4. Diseño orientado a Objetos II

A. Diagrama de Clases. Craig Larman., Cap. 21

a. Generalización.

a. Agregación.

a. Composición.




E. Diagrama de Transición de estado.

Una Arquitectura común en los sistemas de información, que abarca una interfaz para el usuario y el almacenamiento persistente de datos se conoce como ARQUITECTURA DE 3 CAPAS. Las mismas se reseñan así:

1)Capa de Presentación: Ventanas, reportes, etc.2)Capa de Lógica de Aplicaciones: Tareas y reglas que

rigen el Proceso.3)Capa de Almacenamiento: Mecanismos de

Almacenamiento Persistente de los Datos.

ARQUITECTURA CLASICA DE 3 CAPAS


La ventaja de la Arquitectura de 3 Capas reside en que la misma aísla la Capa de Lógica de la Aplicación; y la convierte en una Capa Intermedia BIEN DEFINIDA, reservada únicamente para la Lógica del Software.

En la Capa de Presentación se realiza relativamente bajo procesamiento de la Aplicación: las ventanas envían a la Capa Intermedia peticiones de trabajos.

La Capa de Lógica se comunica con el Almacenamiento, en el extremo opuesto del esquema.


Esta arquitectura contrasta con el Diseño de 2 Capas, donde colocamos la Lógica de las Aplicaciones junto con las definiciones de las Ventanas; que leen y escriben directamente sobre la Base de Datos.

En el esquema de 2 Capas no existe una intermedia que separe la Lógica.

Desventaja de la Arquitectura de 2 Capas: Imposibilidad de representar la Lógica en Componentes Aislados; lo cual dificulta reutilizar el Software.

Es difícil distribuir la Lógica de las Aplicaciones en un equipo diferente.


Si dividimos las responsabilidades que tenemos en la Arquitectura de 3 Capas básica, podemos acceder a arquitecturas multicapas.

Podemos, por ejemplo, subdividir la Capa de Lógica de las Aplicaciones en otras dos, menos densas:

1)Objetos del Dominio: Integrada por las Clases que representan los Objetos del Dominio (por ejemplo, una VENTA).

2)Servicios: Podemos incluir aquí la Interacción de las Bases de Datos, los Reportes, las Comunicaciones y la Seguridad.

ARQUITECTURA MULTICAPAS


Por eso podríamos prescindir de llamarle “Arquitectura 3 Capas”, y hablar, en cambio de “Arquitectura Multicapas”.

En esta “Multicapa” está implícita la capa intermedia de “Lógica de las Aplicaciones”.

Aún podemos seguir descomponiendo las capas ya existentes, y agregando nuevas “subcapas”.

Por ejemplo, la Capa de Servicios bien podría dividirse en: Servicios de Alto y de Bajo Nivel (por ejemplo, generación de Reportes y Servicios de Entrada/Salida respectivamente).


Una Arquitectura Lógica de 3 Capas o más puede desplegarse (es decir, IMPLEMENTARSE FISICAMENTE) en varias configuraciones, como ser:

1)Capas de la Lógica de la Presentación y de Aplicaciones en la computadora del cliente, en su Almacenamiento, o en su Servidor.

2)La Presentación, en la computadora del cliente, la Lógica de Aplicaciones, en un Servidor de Aplicaciones, y el Almacenamiento, en un Servidor de Datos independiente.

ARQUITECTURA MULTICAPAS (DESPLIEGUE)

Gracias al mayor uso de lenguajes y tecnologías que facilitan el procesamiento distribuido (Java), el despliegue de los subsistemas tenderá a hacerse, a su vez también, en forma DISTRIBUIDA.

Motivos para utilizar la Arquitectura Multicapas:1)Aislamiento de la capa de Lógica de las Aplicaciones en

componentes independientes, susceptibles de reutilizarse, después, en otros sistemas.

2)Distribución de las capas en varios nodos físicos de cómputo y en varios procesos. Esto puede mejorar el desempeño, la coordinación y el compartir la información en un sistema cliente-servidor.


3) Asignación de los diseñadores que construyan determinadas capas. Por ejemplo, destinar un equipo a trabajar exclusivamente en la Capa de Presentación; otro grupo especializado en las actividades de desarrollo, etc.

¿Cómo mostrar la Arquitectura con Paquetes en UML?

UML tiene un mecanismo (los paquetes), que permiten describir los grupos de elementos, o subsistemas. Un paquete es un conjunto de cualquier tipo de elementos o modelo: Clases, Casos de Uso, Diagramas de Colaboración u otros Paquetes.


Un paquete se muestra gráficamente como una carpeta con etiquetas.

Los paquetes subordinados se incluyen en su interior. El nombre del paquete se encuentra DENTRO DE LA

ETIQUETA, si el paquete describe sus elementos. En caso contrario, si el Paquete no describe sus

elementos, el nombre del mismo se consigna en el CENTRO de la carpeta.

NOTACIÓN DE PAQUETES EN UML


Los Paquetes nos permiten describir la Arquitectura de un Sistema, usando la notación UML.

En la figura siguiente vemos los agrupamientos lógicos de la Arquitectura Multicapas utilizando los Diagramas de Paquetes de UML.

A este diagrama le podemos llamar “Diagrama de Paquetes de la Arquitectura”.




Esta figura contiene una descomposición más detallada de algunos paquetes comunes en la Arquitectura de un Sistema de Información, así como las dependencias entre ellos:

Entre los paquetes de Servicios de Alto Nivel, podemos citar a:

Reportes Interfaces de Bases de Datos Mecanismos de Seguridad Pautas de Comunicaciones entre procesos Preparados todos ellos con Tecnología Orientada a

Objetos. Normalmente, estos paquetes son desarrollados por los

diseñadores de las Aplicaciones.

SERVICIOS DE ALTO NIVEL

Los Servicios de Bajo Nivel, en cambio, ofrecen prestaciones básicas, como la manipulación de ventanas y archivos, y se pueden adquirir a un proveedor, u obtenerse de bibliotecas del lenguaje que se utilice.

Las bibliotecas de soporte permiten crear ventanas, definir coordinadores de aplicaciones, acceder a bases de datos y archivos, comunicaciones entre procesos, etc.

SERVICIOS DE BAJO NIVEL

Agrupe los elementos en un paquete, aplicando la siguiente directriz:

Agrupe los elementos en un paquete para ofrecer en él un servicio común (o una familia de servicios relacionados), con un nivel relativamente alto de acoplamiento y de colaboración.

En cierto nivel de abstracción, se verá a un paquete como muy cohesivo (con responsabilidades estrechamente relacionadas).

En cambio, habrá relativamente bajo nivel de acoplamiento y colaboración entre los elementos que integran un paquete.

IDENTIFICACION DE LOS PAQUETES

Estratos y Particiones

La Arquitectura Multicapas está compuesta por Estratos (subcapas) y Particiones.

Los Estratos de una arquitectura representan las Capas Verticales; mientras que las Particiones, representan la División Horizontal en subsistemas relativamente paralelos de un estrato.

Por ejemplo: el Estrato de Servicios puede subdividirse en las Particiones de Seguridad y de Reportes.

Estratos y Particiones


Objetos II4. Diseño orientado a Objetos II Craig Larman., Cap.

21A. Diagrama de Clases.

a. Generalización.

a. Agregación.

a. Composición.




E. Diagrama de Transición de estado. Craig Larman., Cap. 33

Evento: Acontecimiento importante o digno de señalarse. Ejemplo: Levantar el “tubo” de un teléfono. Estado: Condición de un objeto en un momento determinado

(o sea, en el lapso que transcurre entre dos eventos). Ejemplo: El teléfono se encuentra en estado “ocioso” mientras está

“colgado” y nadie levante el “tubo”. Transición: Relación entre DOS “estados”. Indica que, cuando

sucede un “evento”, el objeto pasa del “estado” anterior al siguiente “estado”.

Ejemplo: Cuando ocurre el evento “levantar tubo”, el teléfono transiciona del estado “ocioso” hacia el “activo”.

Diagramas de Estado

Un Diagrama de Estado en UML describe visualmente los estados y eventos más interesantes de un objeto; así como su comportamiento frente a un evento.

Diagramas de Estado

Las transiciones se muestran con flechas, que llevan el nombre del evento respectivo.

Los estados se colocan en óvalos. Se suele incluir un estado “inicial”. El Diagrama de Estado exhibe el ciclo de vida de un

objeto: los eventos que le ocurren, sus transiciones y los estados que median entre esos eventos.

No es necesario mostrar todos los eventos posibles, en forma exhaustiva.

A veces se excluyen algunos eventos irrelevantes.

Diagramas de Estado

Podemos crear un Diagrama de Estado que describa el Ciclo de Vida de un Objeto en niveles arbitrariamente simples o complejos, según las necesidades del momento.

Un Diagrama de Estado puede aplicarse a varios elementos de UML, a saber:

1)Clases de Software.2)Tipos (Conceptos).3)Casos de Uso.4)Todo el Sistema.

Diagramas de Estado

Se utilizan para describir la secuencia permitida de eventos EXTERNOS del sistema, dentro de un caso de uso.

Un Diagrama de Estado que describe los eventos GLOBALES del Sistema y su secuencia en un Caso de Uso, es un Diagrama de Estado para los Casos de Uso.

Diagramas de Estado para los Casos de Uso

El Diagrama de la figura siguiente constituye una versión simplificada de los eventos del sistema para el Caso de Uso ComprarProductos, dentro de la aplicación del Punto de Venta.

Este ejemplo nos muestra que no es correcto generar un evento efectuarPago si el evento terminarVenta no ha hecho transicionar al sistema hacia el estado EnEsperadePago.



El número de eventos de un sistema y su orden correcto, en el Caso de Uso ComprarProductos parecen obvios; por eso a veces es innecesario usar un Diagrama de Estado para señalar la secuencia correcta.

Sin embargo, en un caso complejo, con multitud de eventos del sistema, conviene recurrir a un Diagrama de Estado para describir mejor el orden permitido de los eventos externos.


Durante las Fases de Diseño e Implementación, hay que preparar e implementar un Diseño que garantice que no ocurran eventos fuera de la secuencia, para evitar cualquier condición de error.

Por ejemplo, no debe permitirse que CAJA reciba un pago si no ha concluído aún la Venta. Este recaudo deberá tenerse en cuenta al programar.

Con un conjunto de Diagramas de Estado para los Casos de Uso, el diseñador podrá desarrollar metódicamente, garantizando el orden correcto de los eventos del sistema.


Es una variante de los Diagramas de Estado. Muestra las transiciones de los eventos del

Sistema a lo largo de todos los Casos de Uso. Es la unión de todos los Diagramas de

Estado; y resulta útil mientras el número total de eventos sistémicos sea lo suficientemente pequeño que lo tornen manejable.

Diagramas de Estado del

Sistema Global

Diagramas de Estado de Casos de Uso para el

Punto de Venta

Además de los Diagramas de Estado para los Casos de Uso o el Sistema Global, podemos crear Diagramas para cualquier Tipo o Clase.

Tipos Independientes y Dependientes del Estado: Tipos Independientes del Estado: Cuando un objeto siempre

reacciona igual ante un evento, se llama objeto “independiente del estado” con respecto a ese evento.

Por ejemplo: si un objeto recibe un mensaje, y si su método de respuesta siempre hace lo mismo, el método no tiene “lógica condicional”.

El Objeto será INDEPENDIENTE del estado para ese MENSAJE.

Diagramas de Estado para Tipos y Clases

Tipos Dependientes del Estado: Reaccionan de manera distinta ante los eventos, según el estado de éstos.

Conviene preparar Diagramas de Estado para Tipos Dependientes del Estado con comportamiento complejo.

No son muy comunes en el mundo de los sistemas de información para las empresas.

Son más interesantes en el dominio de control de procesos y las telecomunicaciones.

Diagramas de Estado para Tipos y Clases

Un Diagrama de Actividad es un caso especial de un Diagrama de Estados.

Un Diagrama de Actividad está asociado a la implementación de un Caso de Uso. El propósito de este diagrama es enfocarse en los flujos manejados por el procesamiento interno (en contraposición con eventos externos).

Se debe usar Diagrama de Actividad en situaciones donde todos o la mayoría de los eventos representan acciones generadas internamente.

Diagramas de Actividadpara otros autores

Como los Casos de Uso se centran en la interacción entre el actor y el sistema, y no en el procesamiento interno del sistema durante el Caso de Uso, algunos autores proponen utilizar este diagrama, para evitar que la documentación de las actividades del sistema se limite únicamente al texto informal de los Casos de Uso.

Así, un Caso de Uso puede estar acompañado por uno o más Diagramas de Actividad.

Si resulta necesario, se pueden construir Diagramas de Actividad jerárquicos, donde una actividad de un diagrama sea descompuesta en actividades menores en un diagrama de nivel inferior.

Diagramas de Actividadpara otros autores

Son Diagramas de Estado que muestran eventos internos, recibidos de otros objetos.

Craig Larman sostiene que los Diagramas de Colaboración ya contienen los mensajes y las reacciones de los objetos ante estímulos internos de sus pares.

Entonces. ¿Para qué utilizar Diagramas de Actividad para describir los eventos internos, que ya se describen adecuadamente en otro artefacto?.

Diagramas de ActividadVisión de Craig Larman

El Diseño Orientado a Objetos se basa en la filosofía de que los objetos colaboran a través de mensajes para llevar a cabo tareas.

Este enfoque se explicita directamente en los Diagramas de Colaboración de UML: intercambio de mensajes e interacción entre los objetos.

Por lo tanto, sostiene Larman, es incongruente mostrar exactamente lo mismo en un Diagrama de Estado para Eventos Internos o Diagrama de Actividad.

Desde un punto de vista abstracto, ambas perspectivas son equivalentes.


Por eso Larman no recomienda su utilización, para evitar confusiones o contradicciones.

En cambio, sostiene Larman, los Diagramas de Estado para los Eventos EXTERNOS son una herramienta breve y de gran utilidad.

Prefiera Diagramas de Estado para describir eventos EXTERNOS y TEMPORALES, así como su reacción frente a los mismos.

No los utilice para diseñar el comportamiento de los objetos a partir de los eventos INTERNOS.


Documents

Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Actividad