sesion 6 3 diseño particionamiento de dominio

Diseño:Particionamiento de Dominio

Lic. César Alcántara Loayza

CAL/Fundamentos 2

Particionando El Dominio Particionar el dominio es un proceso de

dividir un dominio de problema en unidades cohesivas antes de proceder al diseño detallado. El dominio del problema se ha definido en las dos primeras fases usando los modelos de casos de uso, el modelo de objetos y el modelo dinámico.

CAL/Fundamentos 3

Para una revisión de Paquetes vea la PPT. UML - Paquetes

Particionando El Dominio

CAL/Fundamentos 4


Cada uno de los modelos Revelan algunas cosas diferentesAcerca del dominio del problema.

El dominio del problema fue Definido durante la iniciación del proyecto y El análisis del problema.

Modelo de Casos de Uso

Define espectativas del usuario por el sistemaIdentifica características requeridas del sistemaIdentifica dependencias entre características

Modelo de Objetos

Define recursos usados por el dominio del problemaDefine la estructura de los recursosDefine las relaciones entre recursos

Modelo Dinámico

Define como los recursos interactúan uno con otroDefine las interfaces entre los objetos del dominioDefine las dependencias entre objetos del dominio

CAL/Fundamentos 5

El modelo de casos de uso describe lo que los usuarios esperan ver cuando interactúen con el sistema. Estas espectativas son expresadas en objetivos. Como “Retirar dinero” y “transferir fondos” estos objetivos implican funcionalidad. Por ejemplo, el usuario debe ser capaz de proporcionar un número de cuenta bancario y el monto de dinero a retirar. Los casos de uso proveen la base para el particionamiento funcional.


CAL/Fundamentos 6

El modelo de objetos define los recursos del dominio del problema. Estos recursos son la información que el sistema debe manejar para soportar los casos de uso. Los casos de uso pueden crear o alterar recursos o simplemente acceder a la información que el objeto posee. Consecuentemente, el modelo de objetos es particionado para coincidir con las particiones funcionales.


CAL/Fundamentos 7

El modelo dinámico incluye dos tipos de diagramas de interacción: el diagrama de secuencia y el diagrama de colaboración. Ambos diagramas ilustran la conversación de los objetos. Describen la comunicación entre los objetos participantes y de este modo proporcionan información valiosa acerca de los atributos e interfaces de los objetos del dominio participantes.


CAL/Fundamentos 8

Cuando se particiona el modelo de objetos, las asociaciones entre objetos deben preservarse porque ellas se traducen en dependencias entre particiones.


CAL/Fundamentos 9

Paquetes Los paquetes proporcionan una

herramienta genérica para agrupar información y modelar elementos. Los contenidos de un paquete son enteramente definidos por el usuario, de modo que los paquetes constituyen una herramienta conveniente para definir las particiones.

CAL/Fundamentos 10

Ejemplo

Paquetes

Ventas<<Domain Package>>

Gestion de Presentaciones

<<Domain Package>>

Icono de Paquete

Nombre del Paquete y Estereotipo

Flecha de dependencia: La partición ventas depende de la partición Gestión de Presentaciones

CAL/Fundamentos 11

Estereotipos Estándares Ver documento de:

Estereotipos

CAL/Fundamentos 12

Paquetes y Subsistemas Los paquetes pueden representar

subsistemas. El objetivo de particionar el dominio es colocar todos los elementos del modelo que definen el comportamiento y sus recursos para el sistema en paquetes cohesivos. Cada paquete representa un subsistema – un subconjunto de la funcionalidad completa del sistema.

CAL/Fundamentos 13

Dependencias De Paquetes Una dependencia indica que el paquete

fuente requiere la asistencia del paquete objetivo, tal como un acceso a un objeto creado y mantenido por el paquete objetivo, o funcionalidad poseida por el paquete objetivo. En el sistema de reserva, por ejemplo, Ud. no puede vender boletos para presentaciones hasta que los asientos de la presentación se hayan definido y cotizado.

CAL/Fundamentos 14

Consecuentemente, el subsistema de ventas podría depender de la Gestión de Asientos, el cual pone los asientos dentro del auditorio. El subsistema de ventas podría también depender de la Gestión de presentaciones, el cual define las presentaciones, y Poner precios, el cual asigna los precios a los sitios de cada presentación.

Dependencias De Paquetes

CAL/Fundamentos 15

Dependencias De Subsistemas

Gestion De Sitios<<Domain Package>>

Poner Precio A Presentaciones

<<Domain Package>>

Ventas<<Domain Package>>

Gestión De Presentaciones

<<Domain Package>>

Requiere que los sitios ya esten definidos en el sistema con una localidad válida

Ventas Necesita los precios asignados a cada asiento en la presentación

Requiere acceso a los asientos dentro de la presentación

Este subsistema definirá las ubicaciones de los asientos en el auditorio

Este subsistema rastrea cuales sitios estan disponibles para la venta en cada presentación

Este subsistema asigna precios a los asientos dentro de cada presentación

CAL/Fundamentos 16

El Proceso De Particionar Tomando los recursos del dominio como

fuente, se puede dividir el proceso de particionar el dominio en tres pasos. Dividir los casos de uso en grupos cohesivos

de uno o mas casos de uso que juntos describan una función del sistema.

Identificar los objetos que utilizan los casos de uso y poner las clases representativas en los paquetes/particiones con los casos de uso.

CAL/Fundamentos 17

Identificar las dependencias entre los paquetes/ particiones evaluando las asociaciones entre las clases participantes y las interacciones que toman lugar entre los objetos asociados.

El Proceso De Particionar

CAL/Fundamentos 18

Recuerde que como cualquier proceso de modelamiento, las tareas son iterativas. agrupe los casos de uso que tengan sentido. Muevase al siguiente paso y trate de asignar clases. Este intento revelará algunos errores o le hará pensar diferente acerca del particionamiento. Continue hasta que esté satisfecho y ellos representen la solución deseada.


CAL/Fundamentos 19

Puede continuar el proceso de refinamiento solicitando input de otros. Use los diagramas para comunicar ideas y para capturar visiones obtenidas a través de revisiones. Esta práctica mantendrá los diagramas actualizados con la comprensión de los requerimientos y los diseños realizados durante el proceso.


CAL/Fundamentos 20

Trate de evitar el hábito de tomar notas y luego actualizar diagramas. Los diagramas se convertirán en otra tarea de documentación molesta y perderá su valor como herramienta para asistir en el proceso de modelado.


CAL/Fundamentos 21

Partición De Casos De Uso Los casos de uso definen la

funcionalidad del dominio del problema estableciendo los objetivos que el sistema debe ayudar a lograr para los usuario. En un aplicación finalizada, los casos de uso se traducen en opciones de menú, transacciones y otras unidades de trabajo discretas.

CAL/Fundamentos 22

Cuando se refinan los casos de uso puede encontrar algunos que definen piezas de una tarea mayor. En este caso, puede hallar multiples casos de uso que podrían necesitar combinarse para proporcionar una unidad de trabajo completa.

Partición De Casos De Uso

CAL/Fundamentos 23

Dividir la funcionalidad del sistema basado en casos de uso es probablemente la parte mas subjetiva del proceso de particionamiento. Cuando Ud. sigue hacia los diagramas de clases e interacción será más claramente visible y podrá probar su efectividad.


CAL/Fundamentos 24

Unidades de trabajo: En algunos casos, un caso de uso define una unidad de trabajo que puede incluirse enteramente en el. Otras veces un grupo de casos de uso definen una unidad de trabajo.


CAL/Fundamentos 25


<<subsystem>>Manejar PlanDePrecios

Crear PlanDe Precio

Crear NivelDe Precio

CrearDescuento

Para crear el plan de Precios Tiene primero que crear el Nivel de precios y descuento De donde pueda escoger.

La única razón para crear un Nivel de precio es para utilizarse en el mismo subsistema donde el usuario pueda usarlo.

De igual forma, los descuentos se crean solo porque son utilizados como parte del plan de precios. Se mantienen juntos con las funciones de plan de precios de manera que se puedan manejar como una unidad.

CAL/Fundamentos 26

Mantenga las siguientes preguntas en mente cuando particione: ¿Podría este caso de uso estar solo? ¿Sería razonable para un usuario

completar su tarea o hacer algo mas? Si es así, trate de aislar el caso de uso en su propia partición.


CAL/Fundamentos 27

¿Podría un usuario usar juntas un grupo de funciones?, si es así, entonces trate de poner los casos de uso juntos en la misma partición.

¿El resultado de una función influye las opciones de otra función?

¿Existe tipo de relaciones de reconciliación, balanceo o ensamble de relaciones entre las funciones?


CAL/Fundamentos 28

Tenga cuidado de copiar solamente la forma en que los usuarios actualmente hacen su trabajo. Haga preguntas de prueba acerca de porque la tarea puede o no, ejecutarse como una unidad. Muy frecuentemente, las personas simplemente hacen cosas de la manera en que las han aprendido, exista o no beneficio substancial o cualquier dependencia fundamental entre las tareas.


CAL/Fundamentos 29

El modelo de objetos en el particionamiento del dominio. Los casos de uso definen el objetivo. Para

llevar a cabo el objetivo, los casos de uso necesitan recursos. Los recursos de los casos de uso son objetos definidos por las clases en el modelo de objetos.

Modelo de Objetos - Partición

CAL/Fundamentos 30

Para asignar clases a particiones de dominio se necesita examinar recursos en dos niveles: ¿qué recursos son creados o controlados

por la partición de dominio? ¿Qué recursos son referenciados por la

partición de dominio pero creados o controlados en otra parte?


CAL/Fundamentos 31

Cada recursos objeto debe ser creado. La pregunta que necesita responder cuando intenta asignar objetos a particiones es, “¿quién es responsable de la creación del objeto?” tipicamente, ud. debería asignar la clase que define los objetos a los casos de uso que crea los objetos. Usualmente hay solo uno o muy pocos casos de uso que crean el mismo tipo de objetos.


CAL/Fundamentos 32

Una vez que se crea el objeto, este puede ser accedido por otros casos de uso en otras particiones a través de la base de datos (repositorio persistente) o a través de cualquier número de componentes servidor de objetos. Los casos de uso “creadores” y “referenciadores” no tienen que conocerse uno al otro.


CAL/Fundamentos 33

Cada clase en el modelo de objetos debe estar asignada a una partición. Este proceso proporciona una medida de la integridad (completness) en la transición entre el análisis y diseño.


CAL/Fundamentos 34

Recursos Referenciados – Cuando una partición de dominio requiere acceso a un recurso éste puede o crear el recurso o buscarlo. Un recurso referenciado puede ser consultado o actualizado. En un lenguaje como Java, este arreglo puede verse como una clase importada. En otras palabras, la definición de clase reside en un paquete pero se usa en el otro paquete. Por esta razón, algunas herramientas soportan el uso de un icono diferente para las clases referenciadas o importadas.


CAL/Fundamentos 35

Ejemplo 1 Partición de dominio Planear precio.


Planear Precio

ActualizarNivelPrecio

ActualizarPlanPrecio

ActualizarDescuento

CAL/Fundamentos 36

Actualiza NivelPrecio crea y mantiene los objetos NivelPrecio


Planear Precio



ActualizarDescuento

NivelPrecio

CAL/Fundamentos 37

Actualiza descuento crea y mantiene los objetos descuento.


Planear Precio



ActualizarDescuento

NivelPrecio

Descuento

DescuentoVolumen DescuentoGrupo

DescuentoValorDescuentoCantidad

CAL/Fundamentos 38

Actualizar PlanPrecio crea y mantiene los objetos PlanPrecio.


Planear Precio



ActualizarDescuento

Descuento

PlanDePrecios

0..*

0..*

0..*

0..*

NivelPrecio

1..*

0..*

1..*

0..*


DescuentoCantidad DescuentoValor

{criterio de calificación}

{criterio de volumen}

CAL/Fundamentos 39

Ningún otro objeto es requerido para establecer y mantener un PlandePrecio, de este modo que no hay referencias adicionales a objetos. La definición completa del subsistema en el siguiente cuadro


CAL/Fundamentos 40

Modelo de Objetos - Partición<<subsystem>>

Planear Precio



ActualizarDescuento

Descuento

PlanDePrecios

0..*

0..*

0..*

0..*

NivelPrecio

1..*

0..*

1..*

0..*


DescuentoCantidad DescuentoValor

{criterio de calificación}

{criterio de volumen}

CAL/Fundamentos 41

Ejemplo 2: Partición de dominio Poner precio a la presentación. Este ejemplo es diferente pues no crea objetos solo enlaces. Identificar las clases que el caso de uso Poner

precio a la presentación referencia. Para hacerlo deberá leer la descripción narrativa del caso de uso. El primer paso en Poner precio a la presentación es seleccionar una presentación. Se indica con un sombreado sobre la clase que ésta pertenece a otra partición pero está referenciando aquí.


CAL/Fundamentos 42

Poner precio a presentación


Presentación

CAL/Fundamentos 43

El siguiente paso es seleccionar el PlanDePrecio para la presentación.



Presentación PlanDePrecios

CAL/Fundamentos 44

Crear el enlace entre Presentación y PrecioDelPlan.



PlanDePrecios

0..1 0..*

Presentación

CAL/Fundamentos 45

Una vez que ha seleccionado la presentación y el PlanDePrecios, debe seleccionar un conjunto de AsientoPresentación para poner precio.



PlanDePrecios

0..1 0..*

Presentación

AsientoPresentacion

CAL/Fundamentos 46

Seleccione el NivelPrecio para asignar al AsientoPresentación



PlanDePrecios

0..1 0..*

Presentación

AsientoPresentacionNivelPrecio1..*

0..*

CAL/Fundamentos 47

Cree un enlace entre NivelPrecio y cada uno de los objetos AsientoPresentación seleccionados.



PlanDePrecios

0..1 0..*

Presentación


0..*

0..*0..1

CAL/Fundamentos 48



PlanDePrecios

0..1 0..*

Presentación


0..*

0..*0..1

<<Subsystem>>Poner Precio Presentación

Definición del Subsistema Final

CAL/Fundamentos 49

Ejercicio Ver documento Word: Diseño – Particionar Casos de Uso.


CAL/Fundamentos 50

Las dependencias describen una relación entre particiones. Ud. puede deducir las dependencias evaluando las asociaciones. Una clase está asociada con otra clase porque existe alguna forma de comunicación entre ellas. Los objetos de una clase podrían consultar por información de otra clase. P.e. El AsientoPresentación podría pedir a Asiento el detalle de sus ubicaciones para imprimir en el boleto.

Particionar Dependencias

CAL/Fundamentos 51

Una forma de hallar la dirección de las dependencias es buscas la dirección de la comunicación entre los objetos. En los diagramas de secuencia y colaboración se ha documentado la forma que los objetos conversan.


CAL/Fundamentos 52

En el siguiente diagrama. Busque los diagramas de interacción donde los dos tipos de objetos se comunican. Ver si la flecha de evento va en una sola dirección o en ambas. La(s) dirección(es) de la flecha de evento le dirá la dirección de la dependencia.


CAL/Fundamentos 53

Vea el Subsistema Gestión de Eventos y el subsistema Gestión de Facilidades. Existen tres asociaciones para examinar entre ellas.


CAL/Fundamentos 54


Evento10..*

Auditorio

1

1PlanPisoAuditorio

1

0..*

PlanPisoEvento 0..* 0..*

1

0..1

Asiento

0..*

0..*

se basa en

se hace en

0..*

0..*1

0..*

1

110..*

0..1

1

Gestión deEventos

Gestión defaci l idades

CAL/Fundamentos 55

Encontrar los diagramas de secuencia o colaboración que muestren la comunicación de los objetos asociados. Aquí tenemos dos diagramas de secuencia que contienen los objetos asociados. Por simplicidad se ha combinado en un solo diagrama con notas en ambos lados.


CAL/Fundamentos 56

Determine la dirección de comunicación entre los dos objetos en cuestión.


CAL/Fundamentos 57

Actualice el diagrama de paquetes para indicar la dirección de la dependencia.


CAL/Fundamentos 58

Dependencia paquetes


Evento10..*

Auditorio

1

1PlanPisoAuditorio

1

0..*

PlanPisoEvento 0..* 0..*

1

0..1

Asiento

0..*

0..*

se basa en

se hace en

0..*

0..*1

0..*

1

110..*

0..1

1

Gestion de Eventos

<<subsystem>>

Gestion de Facilidades

<<subsystem>>

CAL/Fundamentos 59

Dependencia funcional. Una dependencia puede existir entre una función y una clase u objeto. Por ejemplo, el modelo de objetos le dice que las presentaciones deben formar parte de un evento (composición). Para crear un objeto presentación debería invocar el objeto evento, pedir que cree una nueva presentación y agregar el nuevo objeto presentación a su composición. ...


CAL/Fundamentos 60

...La función gestión de presentaciones (caso de uso) inicia la adición, cancelación y reprogramación de presentaciones. Pero gestión de presentaciones depende, para hacer el trabajo, del objeto evento que se encuentra en Gestión de Eventos


CAL/Fundamentos 61

Dependencia de tiempo. Otra forma de identificar dependencias es determinar cual objeto debe existir primero. Por ejemplo, en el subsistema Poner Precios no hay interacción de objeto que pudiera decirle explícitamente en que dirección dibujar la dependencia. Tanto el objeto presentación como el objeto PlanDePrecio han de existir antes que el subsistema de poner precios pueda hacer su trabajo.


CAL/Fundamentos 62

Dependencia entre particiones


Poner precios a Presentación

<<subsystem>>Gestión de

Presentaciones

<<subsystem>>

Planear Precios<<subsystem>>

CAL/Fundamentos 63

Ejercicio: Ver documento word

Diseño – Asignar dependencias


CAL/Fundamentos 64

Resumen El particionamiento del dominio proporciona

una división del sistema completo en unidades cohesivas de trabajo. En las aplicaciones culminadas estas unidades se pueden combinar para soportar diferentes flujos de trabajo (workflows) o deberes. El particionamiento de dominio también fija la fase de particionamiento arquitectural pues cada tipo de trabajo o funcionalidad podría implicar una solución arquitectural diferente.

CAL/Fundamentos 65

¿cómo dividiría el particionamiento de dominio? Debe primero asignar cada caso de uso y cada clase de sus modelos de análisis a una partición de dominio y todas las asociaciones del modelo de objetos deben preservarse. Nada debe perderse en la transición del análisis al diseño.

Resumen

sesion 6 3 diseño particionamiento de dominio

Documents