visibilidad. paquetes, estratos y particiones. diagramas de estado y de actividad
Post on 13-Jun-2015
2.931 Views
Preview:
TRANSCRIPT
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.
Visibilidad declarada localmente
Visibilidad declarada localmente
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
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.
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
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.
ARQUITECTURA CLASICA DE 3 CAPAS
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.
ARQUITECTURA CLASICA DE 3 CAPAS
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
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).
ARQUITECTURA MULTICAPAS
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.
ARQUITECTURA MULTICAPAS
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.
ARQUITECTURA MULTICAPAS
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
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”.
NOTACIÓN DE PAQUETES EN UML
NOTACIÓN DE PAQUETES EN UML
NOTACIÓN DE PAQUETES EN UML
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
Contenidos de la Unidad 4Diseño Orientado a
Objetos II4. Diseño orientado a Objetos II Craig Larman., Cap.
21A. Diagrama de Clases.
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
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.
Diagramas de Estado para los Casos de Uso
Diagramas de Estado para los Casos de Uso
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.
Diagramas de Estado para los Casos de Uso
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.
Diagramas de Estado para los Casos de Uso
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.
Diagramas de ActividadVisión de Craig Larman
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.
Diagramas de ActividadVisión de Craig Larman
top related