Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
Contenidos de la Unidad 4 Diseño Orientado a Objetos II <ul><li>Diseño orientado a Objetos II </li></ul><ul><li>Diagrama d...
Visibilidad Craig Larman, Cap. 20 Ingeniería en Sistemas de Información
<ul><li>Es la capacidad de un objeto para ver a otro o hacer referencia a él . </li></ul><ul><li>Los  Diagramas de Colabor...
Visibilidad <ul><li>En el ejemplo siguiente, el mensaje “ Captura ” enviado por  CAJA  a  Venta  significa que  Venta  es,...
<ul><li>Cuando se construye un Diseño de Objetos que interactúan, debemos asegurarnos de que exista la VISIBILIDAD necesar...
<ul><li>“ Para que un Objeto A envíe un mensaje a un Objeto B, éste debe ser visible a aquél ”. </li></ul><ul><li>Por ejem...
<ul><li>Existe Visibilidad de Atributos de A hacia B, cuando B es un ATRIBUTO de A . </li></ul><ul><li>Se trata de una  VI...
<ul><li>Existe  Visibilidad de Parámetros  de  A  hacia  B , cuando  B  se transmite como un parámetro a un  Método  de  A...
Visibilidad de Parámetros
<ul><li>Existe  Visibilidad Declarada Localmente  de  A  hacia  B  cuando se declara que  B es un objeto local, dentro de ...
<ul><li>Existen dos medios habituales para lograr esta forma de Visibilidad: </li></ul><ul><li>Crear una nueva  Instancia ...
Visibilidad declarada localmente
<ul><li>Existe Visibilidad Global de A hacia B, cuando B es GLOBAL para A . </li></ul><ul><li>Se trata de una  Visibilidad...
Visibilidad
Contenidos de la Unidad 4 Diseño Orientado a Objetos II <ul><li>Diseño orientado a Objetos II </li></ul><ul><li>Diagrama d...
<ul><li>Una Arquitectura común en los sistemas de información, que abarca una  interfaz para el usuario  y el  almacenamie...
ARQUITECTURA CLASICA DE 3 CAPAS
<ul><li>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...
<ul><li>Esta arquitectura contrasta con el Diseño de 2 Capas, donde colocamos la Lógica de las Aplicaciones junto con las ...
<ul><li>Si dividimos las responsabilidades que tenemos en la  Arquitectura de 3 Capas básica , podemos acceder a arquitect...
ARQUITECTURA MULTICAPAS
<ul><li>Por eso podríamos prescindir de llamarle “ Arquitectura 3 Capas ”, y hablar, en cambio de “ Arquitectura Multicapa...
<ul><li>Una Arquitectura Lógica de 3 Capas o más puede desplegarse (es decir,  IMPLEMENTARSE FISICAMENTE ) en varias confi...
<ul><li>Gracias al mayor uso de lenguajes y tecnologías que facilitan el procesamiento distribuido (Java), el despliegue d...
<ul><li>3)  Asignación de los diseñadores que construyan  determinadas capas. Por ejemplo, destinar un equipo a trabajar e...
<ul><li>Un paquete se muestra gráficamente como una  carpeta con etiquetas . </li></ul><ul><li>Los paquetes subordinados s...
NOTACIÓN DE PAQUETES EN UML
<ul><li>Los Paquetes nos permiten describir la Arquitectura de un Sistema, usando la notación UML. </li></ul><ul><li>En la...
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 Arquit...
<ul><li>Entre los paquetes de  Servicios de Alto Nivel , podemos citar a:  </li></ul><ul><li>Reportes </li></ul><ul><li>In...
<ul><li>Los  Servicios de Bajo Nivel , en cambio, ofrecen prestaciones básicas, como la manipulación de ventanas y archivo...
<ul><li>Agrupe los elementos en un paquete, aplicando la siguiente directriz: </li></ul><ul><li>Agrupe los elementos en un...
Estratos y Particiones
<ul><li>La  Arquitectura Multicapas  está compuesta por  Estratos  (subcapas) y  Particiones . </li></ul><ul><li>Los  Estr...
Contenidos de la Unidad 4 Diseño Orientado a Objetos II <ul><li>Diseño orientado a Objetos II </li></ul>Craig Larman., Cap...
<ul><li>Evento:   Acontecimiento importante o digno de señalarse . </li></ul><ul><li>Ejemplo : Levantar el “ tubo ” de un ...
<ul><li>Un  Diagrama de Estado  en  UML  describe  visualmente  los  estados  y  eventos   más interesantes  de un  objeto...
<ul><li>Las  transiciones  se muestran con  flechas , que llevan el nombre del  evento  respectivo.  </li></ul><ul><li>Los...
<ul><li>Podemos crear un  Diagrama de Estado  que describa el  Ciclo de Vida de un Objeto  en niveles  arbitrariamente sim...
<ul><li>Se utilizan para  describir la secuencia permitida de eventos EXTERNOS del sistema , dentro de un  caso de uso . <...
<ul><li>El  Diagrama  de la figura siguiente constituye una versión simplificada de los eventos del sistema para el  Caso ...
Diagramas de Estado para los Casos de Uso
<ul><li>El número de eventos de un sistema y su orden correcto, en el  Caso de Uso   ComprarProductos  parecen obvios; por...
<ul><li>Durante las  Fases de Diseño  e  Implementación , hay que preparar e implementar un  Diseño   que garantice que  n...
<ul><li>Es una  variante   de los  Diagramas de Estado . </li></ul><ul><li>Muestra las  transiciones  de los  eventos  del...
Diagramas de Estado de Casos de Uso  para el Punto de Venta
<ul><li>Además de los  Diagramas de Estado para los Casos de Uso  o el  Sistema Global , podemos crear  Diagramas  para cu...
<ul><li>Tipos Dependientes del Estado :  Reaccionan de manera distinta ante los eventos , según el estado de éstos. </li><...
<ul><li>Un  Diagrama de Actividad  es un  caso especial  de un  Diagrama de Estados . </li></ul><ul><li>Un  Diagrama de Ac...
<ul><li>Como los  Casos de Uso  se centran en la  interacción  entre el  actor   y el  sistema , y  no en el procesamiento...
<ul><li>Son  Diagramas de Estado  que muestran eventos internos, recibidos de otros objetos. </li></ul><ul><li>Craig Larma...
<ul><li>El  Diseño Orientado a Objetos  se basa en la filosofía de que los  objetos colaboran a través de mensajes para ll...
<ul><li>Por eso  Larman  no recomienda su utilización, para evitar confusiones o contradicciones. </li></ul><ul><li>En cam...
Upcoming SlideShare
Loading in …5
×

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

3,617 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,617
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
136
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
  2. 2. Contenidos de la Unidad 4 Diseño Orientado a Objetos II <ul><li>Diseño orientado a Objetos II </li></ul><ul><li>Diagrama de Clases. </li></ul>  Craig Larman., Cap. 21 <ul><ul><li>Generalización. </li></ul></ul>  <ul><ul><li>Agregación. </li></ul></ul>  <ul><ul><li>Composición. </li></ul></ul>  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
  3. 3. Visibilidad Craig Larman, Cap. 20 Ingeniería en Sistemas de Información
  4. 4. <ul><li>Es la capacidad de un objeto para ver a otro o hacer referencia a él . </li></ul><ul><li>Los Diagramas de Colaboración (para cada Evento del Sistema ) describen gráficamente los mensajes entre Objetos. </li></ul><ul><li>Para que un Objeto Emisor envíe un mensaje a un Objeto Receptor , éste tiene que ser VISIBLE a aquél. </li></ul>Visibilidad Introducción
  5. 5. Visibilidad <ul><li>En el ejemplo siguiente, el mensaje “ Captura ” enviado por CAJA a Venta significa que Venta es, de alguna manera, VISIBLE a CAJA . </li></ul>CAJA IntroducirProducto() Venta fecha estaTerminada: Booleano hora IntroducirProducto() Captura 1 1
  6. 6. <ul><li>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. </li></ul><ul><li>Hay 4 formas comunes de conseguir visibilidad del Objeto A hacia el Objeto B : </li></ul><ul><li>Visibilidad de Atributos: B es un atributo de A . </li></ul><ul><li>Visibilidad de Parámetros: B es un parámetro de un Método de A . </li></ul><ul><li>Visibilidad Declarada Localmente: Se declara que B es un objeto local en un método de A. </li></ul><ul><li>Visibilidad Global: En alguna forma, B es visible globalmente. </li></ul>Visibilidad
  7. 7. <ul><li>“ Para que un Objeto A envíe un mensaje a un Objeto B, éste debe ser visible a aquél ”. </li></ul><ul><li>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 . </li></ul><ul><li>Una solución usual suele consistir en conservar, como atributo de CAJA , una referencia a Venta ( Visibilidad de ATRIBUTO ). </li></ul>Visibilidad
  8. 8. <ul><li>Existe Visibilidad de Atributos de A hacia B, cuando B es un ATRIBUTO de A . </li></ul><ul><li>Se trata de una VISIBILIDAD relativamente permanente , ya que subsiste mientras existan A y B . </li></ul><ul><li>Es una forma muy común de visibilidad en los sistemas orientados a objetos. </li></ul>Visibilidad de Atributos
  9. 9. <ul><li>Existe Visibilidad de Parámetros de A hacia B , cuando B se transmite como un parámetro a un Método de A . </li></ul><ul><li>Se trata de una Visibilidad relativamente TEMPORAL ; pues subsiste sólo dentro del ámbito del Método. </li></ul><ul><li>Después de la Visibilidad de Atributo , es la forma más común de Visibilidad , en los sistemas orientados a objetos. </li></ul><ul><li>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 . </li></ul><ul><li>Entonces, dentro del ámbito del método “ hacerlineadeproducto ”, Venta tiene Visibilidad de Parámetro hacia EspecificaciondeProducto . </li></ul>Visibilidad de Parámetros
  10. 10. Visibilidad de Parámetros
  11. 11. <ul><li>Existe Visibilidad Declarada Localmente de A hacia B cuando se declara que B es un objeto local, dentro de un método de A . </li></ul><ul><li>Se trata de una Visibilidad relativamente TEMPORAL , pues persiste únicamente dentro del ámbito del Método . </li></ul><ul><li>Después de la Visibilidad de Parámetros , es la TERCERA más utilizada, en los sistemas orientados a objetos. </li></ul>Visibilidad declarada localmente
  12. 12. <ul><li>Existen dos medios habituales para lograr esta forma de Visibilidad: </li></ul><ul><li>Crear una nueva Instancia Local y asignarle una Variable Local . </li></ul><ul><li>Asignar a una Variable Local el Objeto devuelto, proveniente de la llamada el Método . </li></ul>Visibilidad declarada localmente
  13. 13. Visibilidad declarada localmente
  14. 14. <ul><li>Existe Visibilidad Global de A hacia B, cuando B es GLOBAL para A . </li></ul><ul><li>Se trata de una Visibilidad relativamente PERMANENTE ; pues persiste mientras existan A y B . </li></ul><ul><li>Es la Visibilidad MENOS FRECUENTE en los sistemas orientados a objetos. </li></ul><ul><li>Es la forma más obvia ( aunque menos conveniente ) de alcanzar la Visibilidad Global . </li></ul><ul><li>Consiste en asignar una instancia a una Variable Global . </li></ul>Visibilidad global
  15. 15. Visibilidad
  16. 16. Contenidos de la Unidad 4 Diseño Orientado a Objetos II <ul><li>Diseño orientado a Objetos II </li></ul><ul><li>Diagrama de Clases. </li></ul>  Craig Larman., Cap. 21 <ul><ul><li>Generalización. </li></ul></ul>  <ul><ul><li>Agregación. </li></ul></ul>  <ul><ul><li>Composición. </li></ul></ul>  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.  
  17. 17. <ul><li>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í: </li></ul><ul><li>Capa de Presentación: Ventanas, reportes, etc. </li></ul><ul><li>Capa de Lógica de Aplicaciones: Tareas y reglas que rigen el Proceso. </li></ul><ul><li>Capa de Almacenamiento: Mecanismos de Almacenamiento Persistente de los Datos. </li></ul>ARQUITECTURA CLASICA DE 3 CAPAS
  18. 18. ARQUITECTURA CLASICA DE 3 CAPAS
  19. 19. <ul><li>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 . </li></ul><ul><li>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. </li></ul><ul><li>La Capa de Lógica se comunica con el Almacenamiento , en el extremo opuesto del esquema. </li></ul>ARQUITECTURA CLASICA DE 3 CAPAS
  20. 20. <ul><li>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. </li></ul><ul><li>En el esquema de 2 Capas no existe una intermedia que separe la Lógica. </li></ul><ul><li>Desventaja de la Arquitectura de 2 Capas: Imposibilidad de representar la Lógica en Componentes Aislados; lo cual dificulta reutilizar el Software. </li></ul><ul><li>Es difícil distribuir la Lógica de las Aplicaciones en un equipo diferente. </li></ul>ARQUITECTURA CLASICA DE 3 CAPAS
  21. 21. <ul><li>Si dividimos las responsabilidades que tenemos en la Arquitectura de 3 Capas básica , podemos acceder a arquitecturas multicapas. </li></ul><ul><li>Podemos, por ejemplo, subdividir la Capa de Lógica de las Aplicaciones en otras dos, menos densas: </li></ul><ul><li>Objetos del Dominio: Integrada por las Clases que representan los Objetos del Dominio (por ejemplo, una VENTA). </li></ul><ul><li>Servicios: Podemos incluir aquí la Interacción de las Bases de Datos, los Reportes, las Comunicaciones y la Seguridad. </li></ul>ARQUITECTURA MULTICAPAS
  22. 22. ARQUITECTURA MULTICAPAS
  23. 23. <ul><li>Por eso podríamos prescindir de llamarle “ Arquitectura 3 Capas ”, y hablar, en cambio de “ Arquitectura Multicapas ”. </li></ul><ul><li>En esta “ Multicapa ” está implícita la capa intermedia de “ Lógica de las Aplicaciones ”. </li></ul><ul><li>Aún podemos seguir descomponiendo las capas ya existentes, y agregando nuevas “ subcapas ”. </li></ul><ul><li>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). </li></ul>ARQUITECTURA MULTICAPAS
  24. 24. <ul><li>Una Arquitectura Lógica de 3 Capas o más puede desplegarse (es decir, IMPLEMENTARSE FISICAMENTE ) en varias configuraciones, como ser: </li></ul><ul><li>Capas de la Lógica de la Presentación y de Aplicaciones en la computadora del cliente , en su Almacenamiento , o en su Servidor . </li></ul><ul><li>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. </li></ul>ARQUITECTURA MULTICAPAS (DESPLIEGUE)
  25. 25. <ul><li>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. </li></ul><ul><li>Motivos para utilizar la Arquitectura Multicapas: </li></ul><ul><li>Aislamiento de la capa de Lógica de las Aplicaciones en componentes independientes, susceptibles de reutilizarse, después, en otros sistemas. </li></ul><ul><li>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. </li></ul>ARQUITECTURA MULTICAPAS
  26. 26. <ul><li>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. </li></ul><ul><li>¿Cómo mostrar la Arquitectura con Paquetes en UML? </li></ul><ul><li>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 . </li></ul>ARQUITECTURA MULTICAPAS
  27. 27. <ul><li>Un paquete se muestra gráficamente como una carpeta con etiquetas . </li></ul><ul><li>Los paquetes subordinados se incluyen en su interior. </li></ul><ul><li>El nombre del paquete se encuentra DENTRO DE LA ETIQUETA , si el paquete describe sus elementos. </li></ul><ul><li>En caso contrario, si el Paquete no describe sus elementos , el nombre del mismo se consigna en el CENTRO de la carpeta . </li></ul>NOTACIÓN DE PAQUETES EN UML
  28. 28. NOTACIÓN DE PAQUETES EN UML
  29. 29. <ul><li>Los Paquetes nos permiten describir la Arquitectura de un Sistema, usando la notación UML. </li></ul><ul><li>En la figura siguiente vemos los agrupamientos lógicos de la Arquitectura Multicapas utilizando los Diagramas de Paquetes de UML . </li></ul><ul><li>A este diagrama le podemos llamar “ Diagrama de Paquetes de la Arquitectura ”. </li></ul>NOTACIÓN DE PAQUETES EN UML
  30. 30. NOTACIÓN DE PAQUETES EN UML
  31. 31. 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:
  32. 32. <ul><li>Entre los paquetes de Servicios de Alto Nivel , podemos citar a: </li></ul><ul><li>Reportes </li></ul><ul><li>Interfaces de Bases de Datos </li></ul><ul><li>Mecanismos de Seguridad </li></ul><ul><li>Pautas de Comunicaciones entre procesos </li></ul><ul><li>Preparados todos ellos con Tecnología Orientada a Objetos. </li></ul><ul><li>Normalmente, estos paquetes son desarrollados por los diseñadores de las Aplicaciones. </li></ul>SERVICIOS DE ALTO NIVEL
  33. 33. <ul><li>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. </li></ul><ul><li>Las bibliotecas de soporte permiten crear ventanas, definir coordinadores de aplicaciones, acceder a bases de datos y archivos, comunicaciones entre procesos, etc. </li></ul>SERVICIOS DE BAJO NIVEL
  34. 34. <ul><li>Agrupe los elementos en un paquete, aplicando la siguiente directriz: </li></ul><ul><li>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. </li></ul><ul><li>En cierto nivel de abstracción, se verá a un paquete como muy cohesivo (con responsabilidades estrechamente relacionadas). </li></ul><ul><li>En cambio, habrá relativamente bajo nivel de acoplamiento y colaboración entre los elementos que integran un paquete. </li></ul>IDENTIFICACION DE LOS PAQUETES
  35. 35. Estratos y Particiones
  36. 36. <ul><li>La Arquitectura Multicapas está compuesta por Estratos (subcapas) y Particiones . </li></ul><ul><li>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. </li></ul><ul><li>Por ejemplo: el Estrato de Servicios puede subdividirse en las Particiones de Seguridad y de Reportes . </li></ul>Estratos y Particiones
  37. 37. Contenidos de la Unidad 4 Diseño Orientado a Objetos II <ul><li>Diseño orientado a Objetos II </li></ul>Craig Larman., Cap. 21 <ul><li>Diagrama de Clases. </li></ul>  <ul><ul><li>Generalización. </li></ul></ul>  <ul><ul><li>Agregación. </li></ul></ul>  <ul><ul><li>Composición. </li></ul></ul>  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
  38. 38. <ul><li>Evento: Acontecimiento importante o digno de señalarse . </li></ul><ul><li>Ejemplo : Levantar el “ tubo ” de un teléfono. </li></ul><ul><li>Estado: Condición de un objeto en un momento determinado (o sea, en el lapso que transcurre entre dos eventos). </li></ul><ul><li>Ejemplo : El teléfono se encuentra en estado “ ocioso ” mientras está “ colgado ” y nadie levante el “ tubo ”. </li></ul><ul><li>Transición: Relación entre DOS “ estados ”. Indica que, cuando sucede un “ evento ”, el objeto pasa del “ estado ” anterior al siguiente “ estado ” . </li></ul><ul><li>Ejemplo: Cuando ocurre el evento “ levantar tubo ”, el teléfono transiciona del estado “ ocioso ” hacia el “ activo ”. </li></ul>Diagramas de Estado
  39. 39. <ul><li>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 . </li></ul>Diagramas de Estado
  40. 40. <ul><li>Las transiciones se muestran con flechas , que llevan el nombre del evento respectivo. </li></ul><ul><li>Los estados se colocan en óvalos . </li></ul><ul><li>Se suele incluir un estado “ inicial ”. </li></ul><ul><li>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 . </li></ul><ul><li>No es necesario mostrar todos los eventos posibles, en forma exhaustiva. </li></ul><ul><li>A veces se excluyen algunos eventos irrelevantes. </li></ul>Diagramas de Estado
  41. 41. <ul><li>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. </li></ul><ul><li>Un Diagrama de Estado puede aplicarse a varios elementos de UML, a saber: </li></ul><ul><li>Clases de Software. </li></ul><ul><li>Tipos (Conceptos). </li></ul><ul><li>Casos de Uso. </li></ul><ul><li>Todo el Sistema. </li></ul>Diagramas de Estado
  42. 42. <ul><li>Se utilizan para describir la secuencia permitida de eventos EXTERNOS del sistema , dentro de un caso de uso . </li></ul><ul><li>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 . </li></ul>Diagramas de Estado para los Casos de Uso
  43. 43. <ul><li>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 . </li></ul><ul><li>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 . </li></ul>Diagramas de Estado para los Casos de Uso
  44. 44. Diagramas de Estado para los Casos de Uso
  45. 45. <ul><li>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. </li></ul><ul><li>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. </li></ul>Diagramas de Estado para los Casos de Uso
  46. 46. <ul><li>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 . </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>Diagramas de Estado para los Casos de Uso
  47. 47. <ul><li>Es una variante de los Diagramas de Estado . </li></ul><ul><li>Muestra las transiciones de los eventos del Sistema a lo largo de todos los Casos de Uso . </li></ul><ul><li>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. </li></ul>Diagramas de Estado del Sistema Global
  48. 48. Diagramas de Estado de Casos de Uso para el Punto de Venta
  49. 49. <ul><li>Además de los Diagramas de Estado para los Casos de Uso o el Sistema Global , podemos crear Diagramas para cualquier Tipo o Clase . </li></ul><ul><li>Tipos Independientes y Dependientes del Estado : </li></ul><ul><li>Tipos Independientes del Estado : Cuando un objeto siempre reacciona igual ante un evento , se llama objeto “ independiente del estado ” con respecto a ese evento. </li></ul><ul><li>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 ”. </li></ul><ul><li>El Objeto será INDEPENDIENTE del estado para ese MENSAJE . </li></ul>Diagramas de Estado para Tipos y Clases
  50. 50. <ul><li>Tipos Dependientes del Estado : Reaccionan de manera distinta ante los eventos , según el estado de éstos. </li></ul><ul><li>Conviene preparar Diagramas de Estado para Tipos Dependientes del Estado con comportamiento complejo . </li></ul><ul><li>No son muy comunes en el mundo de los sistemas de información para las empresas . </li></ul><ul><li>Son más interesantes en el dominio de control de procesos y las telecomunicaciones . </li></ul>Diagramas de Estado para Tipos y Clases
  51. 51. <ul><li>Un Diagrama de Actividad es un caso especial de un Diagrama de Estados . </li></ul><ul><li>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 ). </li></ul><ul><li>Se debe usar Diagrama de Actividad en situaciones donde todos o la mayoría de los eventos representan acciones generadas internamente . </li></ul>Diagramas de Actividad para otros autores
  52. 52. <ul><li>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 . </li></ul><ul><li>Así, un Caso de Uso puede estar acompañado por uno o más Diagramas de Actividad . </li></ul><ul><li>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. </li></ul>Diagramas de Actividad para otros autores
  53. 53. <ul><li>Son Diagramas de Estado que muestran eventos internos, recibidos de otros objetos. </li></ul><ul><li>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. </li></ul><ul><li>Entonces. ¿ Para qué utilizar Diagramas de Actividad para describir los eventos internos, que ya se describen adecuadamente en otro artefacto ?. </li></ul>Diagramas de Actividad Visión de Craig Larman
  54. 54. <ul><li>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 . </li></ul><ul><li>Este enfoque se explicita directamente en los Diagramas de Colaboración de UML : intercambio de mensajes e interacción entre los objetos. </li></ul><ul><li>Por lo tanto, sostiene Larman , es incongruente mostrar exactamente lo mismo en un Diagrama de Estado para Eventos Internos o Diagrama de Actividad . </li></ul><ul><li>Desde un punto de vista abstracto, ambas perspectivas son equivalentes . </li></ul>Diagramas de Actividad Visión de Craig Larman
  55. 55. <ul><li>Por eso Larman no recomienda su utilización, para evitar confusiones o contradicciones. </li></ul><ul><li>En cambio, sostiene Larman , los Diagramas de Estado para los Eventos EXTERNOS son una herramienta breve y de gran utilidad. </li></ul><ul><li>Prefiera Diagramas de Estado para describir eventos EXTERNOS y TEMPORALES , así como su reacción frente a los mismos. </li></ul><ul><li>No los utilice para diseñar el comportamiento de los objetos a partir de los eventos INTERNOS . </li></ul>Diagramas de Actividad Visión de Craig Larman

×