sesion 6_3 diseño - particionamiento de dominio

8/3/2019 Sesion 6_3 Diseño - Particionamiento de Dominio

http://slidepdf.com/reader/full/sesion-63-diseno-particionamiento-de-dominio 1/65

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 procederal diseño detallado. El dominio delproblema se ha definido en las dos

primeras fases usando los modelos decasos de uso, el modelo de objetos y elmodelo dinámico.



CAL/Fundamentos 3

Para una revisión de Paquetes vea laPPT. UML - Paquetes

Particionando El Dominio



CAL/Fundamentos 4


Cada uno de los modelos

Revelan algunas cosas diferentes Acerca del dominio del problema

El dominio del problema fue Definidodurante la iniciación del proyecto y Elaná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 dominio

Define las dependencias entre objetos del dominio



CAL/Fundamentos 5

El modelo de casos de uso describe lo quelos usuarios esperan ver cuando interactúencon el sistema. Estas espectativas sonexpresadas en objetivos. Como “Retirardinero” y “transferir fondos” estos objetivosimplican funcionalidad. Por ejemplo, elusuario debe ser capaz de proporcionar unnúmero de cuenta bancario y el monto dedinero a retirar. Los casos de uso proveen labase para el particionamiento funcional.




CAL/Fundamentos 6

El modelo de objetos define los recursos deldominio del problema. Estos recursos son la

información que el sistema debe manejarpara soportar los casos de uso. Los casos deuso pueden crear o alterar recursos osimplemente acceder a la información que el

objeto posee. Consecuentemente, el modelode objetos es particionado para coincidir conlas particiones funcionales.




CAL/Fundamentos 7

El modelo dinámico incluye dos tipos dediagramas de interacción: el diagrama de

secuencia y el diagrama de colaboración. Ambos diagramas ilustran la conversación delos objetos. Describen la comunicación entrelos objetos participantes y de este modo

proporcionan información valiosa acerca delos atributos e interfaces de los objetos deldominio participantes.




CAL/Fundamentos 8

Cuando se particiona el modelo deobjetos, las asociaciones entre objetos

deben preservarse porque ellas setraducen en dependencias entreparticiones.




CAL/Fundamentos 9

Paquetes Los paquetes proporcionan una

herramienta genérica para agrupar

información y modelar elementos. Loscontenidos de un paquete sonenteramente definidos por el usuario,

de modo que los paquetes constituyenuna herramienta conveniente paradefinir las particiones.



CAL/Fundamentos 10

EjemploPaquetes

Ventas<<Domain Package>>

Gestion dePresentaciones

<<Domain Package>>

Icono dePaquete

Nombre del Paquete yEstereotipo

Flecha de dependencia: Lapartición ventas depende de

la partición Gestión dePresentaciones



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 loselementos del modelo que definen elcomportamiento y sus recursos para elsistema en paquetes cohesivos. Cada

paquete representa un subsistema – unsubconjunto de la funcionalidadcompleta 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 objetocreado y mantenido por el paquete objetivo,o funcionalidad poseida por el paqueteobjetivo. En el sistema de reserva, por

ejemplo, Ud. no puede vender boletos parapresentaciones hasta que los asientos de lapresentación se hayan definido y cotizado.



CAL/Fundamentos 14

Consecuentemente, el subsistema deventas podría depender de la Gestión

de Asientos, el cual pone los asientosdentro del auditorio. El subsistema deventas podría también depender de laGestión de presentaciones, el cual

define las presentaciones, y Ponerprecios, el cual asigna los precios a lossitios de cada presentación.

Dependencias De Paquetes



CAL/Fundamentos 15

Dependencias De Subsistemas

Gestion De Sitios<<Domain Package>>

Poner Precio APresentaciones

<<Domain Package>>

Ventas<<Domain Package>>

Gestión DePresentaciones

<<Domain Package>>

Requiere que los sitiosya esten definidos en elsistema con unalocalidad válida

Ventas Necesita losprecios asignados acada asiento en lapresentación

Requiere acceso alos asientos dentrode la presentación

Este subsistemadefinirá lasubicaciones delos asientos en elauditorio

Este subsistemarastrea cuales sitiosestan disponiblespara la venta encada presentación

Este subsistemaasigna precios a losasientos dentro decada 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 juntosdescriban una función del sistema.

Identificar los objetos que utilizan los casosde uso y poner las clases representativas enlos paquetes/particiones con los casos deuso.



CAL/Fundamentos 17

Identificar las dependencias entre lospaquetes/ particiones evaluando las

asociaciones entre las clases participantesy las interacciones que toman lugar entrelos objetos asociados.

El Proceso De Particionar



CAL/Fundamentos 18

Recuerde que como cualquier proceso demodelamiento, las tareas son iterativas.

agrupe los casos de uso que tengan sentido.Muevase al siguiente paso y trate de asignarclases. Este intento revelará algunos erroreso le hará pensar diferente acerca del

particionamiento. Continue hasta que estésatisfecho y ellos representen la solucióndeseada.




CAL/Fundamentos 19

Puede continuar el proceso derefinamiento solicitando input de otros.

Use los diagramas para comunicar ideasy para capturar visiones obtenidas através de revisiones. Esta prácticamantendrá los diagramas actualizados

con la comprensión de losrequerimientos y los diseños realizadosdurante el proceso.




CAL/Fundamentos 20

Trate de evitar el hábito de tomar notasy luego actualizar diagramas. Los

diagramas se convertirán en otra tareade 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 elsistema debe ayudar a lograr para losusuario. En un aplicación finalizada, los

casos de uso se traducen en opcionesde menú, transacciones y otrasunidades de trabajo discretas.



CAL/Fundamentos 22

Cuando se refinan los casos de usopuede encontrar algunos que definenpiezas de una tarea mayor. En estecaso, puede hallar multiples casos deuso que podrían necesitar combinarse

para proporcionar una unidad detrabajo completa.

Partición De Casos De Uso



CAL/Fundamentos 23

Dividir la funcionalidad del sistemabasado 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ásclaramente visible y podrá probar suefectividad.




CAL/Fundamentos 24

Unidades de trabajo: En algunos casos,un caso de uso define una unidad de

trabajo que puede incluirseenteramente en el. Otras veces ungrupo de casos de uso definen una

unidad de trabajo.




CAL/Fundamentos 25


<<subsystem>>Manejar PlanDePrecios

Crear PlanDe Precio

Crear NivelDe Precio

Crear

Descuento

Para crear el plan de Precios Tieneprimero que crear el Nivel de precios ydescuento De donde pueda escoger.

La única razón paracrear un Nivel de precioes para utilizarse en elmismo subsistema

donde el usuario puedausarlo.

De igual forma, los descuentos se crean solo porque son utilizados comoparte 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 enmente 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 supropia partición.




CAL/Fundamentos 27

¿Podría un usuario usar juntas un grupo defunciones?, si es así, entonces trate de

poner los casos de uso juntos en la mismapartición.

¿El resultado de una función influye lasopciones de otra función?

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




CAL/Fundamentos 28

Tenga cuidado de copiar solamente la formaen que los usuarios actualmente hacen su

trabajo. Haga preguntas de prueba acerca deporque la tarea puede o no, ejecutarse comouna unidad. Muy frecuentemente, laspersonas simplemente hacen cosas de la

manera en que las han aprendido, exista o nobeneficio substancial o cualquier dependenciafundamental entre las tareas.




CAL/Fundamentos 29

El modelo de objetos en elparticionamiento del dominio.

Los casos de uso definen el objetivo. Parallevar a cabo el objetivo, los casos de usonecesitan recursos. Los recursos de loscasos de uso son objetos definidos por lasclases en el modelo de objetos.

Modelo de Objetos - Partición



CAL/Fundamentos 30

Para asignar clases a particiones dedominio se necesita examinar recursos

en dos niveles: ¿qué recursos son creados o controlados

por la partición de dominio?

¿Qué recursos son referenciados por lapartición de dominio pero creados ocontrolados en otra parte?




CAL/Fundamentos 31

Cada recursos objeto debe ser creado. Lapregunta que necesita responder cuando

intenta asignar objetos a particiones es, “¿quién es responsable de la creación delobjeto?” tipicamente, ud. debería asignar laclase que define los objetos a los casos de

uso que crea los objetos. Usualmente haysolo uno o muy pocos casos de uso que creanel mismo tipo de objetos.




CAL/Fundamentos 32

Una vez que se crea el objeto, estepuede ser accedido por otros casos de

uso en otras particiones a través de labase de datos (repositorio persistente)o a través de cualquier número decomponentes servidor de objetos. Los

casos de uso “creadores” y “referenciadores” no tienen queconocerse uno al otro.




CAL/Fundamentos 33

Cada clase en el modelo de objetosdebe estar asignada a una partición.

Este proceso proporciona una medidade la integridad (completness) en latransición entre el análisis y diseño.




CAL/Fundamentos 34

Recursos Referenciados – Cuando una particiónde dominio requiere acceso a un recurso éstepuede o crear el recurso o buscarlo. Un recursoreferenciado puede ser consultado o actualizado.En un lenguaje como Java, este arreglo puedeverse como una clase importada. En otraspalabras, la definición de clase reside en un

paquete pero se usa en el otro paquete. Por estarazón, algunas herramientas soportan el uso deun icono diferente para las clases referenciadas oimportadas.




CAL/Fundamentos 35

Ejemplo 1 Partición de dominio Planear precio.Modelo de Objetos - Partición

Planear Precio

ActualizarNivelPrecio

ActualizarPlanPrecio

ActualizarDescuento



CAL/Fundamentos 36

Actualiza NivelPrecio crea y mantiene los objetosNivelPrecio


Planear Precio



ActualizarDescuento

NivelPrecio



CAL/Fundamentos 37

Actualiza descuento crea y mantiene losobjetos descuento.


Planear Precio



ActualizarDescuento

NivelPrecio

Descuento

DescuentoVolumen DescuentoGrupo

DescuentoValorDescuentoCantidad



CAL/Fundamentos 38

Actualizar PlanPrecio crea y mantiene los objetosPlanPrecio.


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 paraestablecer y mantener un PlandePrecio, deeste modo que no hay referenciasadicionales a objetos. La definicióncompleta del subsistema en el siguientecuadro




CAL/Fundamentos 40

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


Actualizar

PlanPrecio

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 precioa la presentación. Este ejemplo es diferentepues no crea objetos solo enlaces. Identificar las clases que el caso de uso Poner

precio a la presentación referencia. Para hacerlodeberá leer la descripción narrativa del caso deuso. El primer paso en Poner precio a la

presentación es seleccionar una presentación. Seindica con un sombreado sobre la clase que éstapertenece a otra partición pero está referenciandoaquí.




CAL/Fundamentos 42

Poner precio apresentación


Presentación



CAL/Fundamentos 43

El siguiente paso es seleccionar el PlanDePrecio parala presentación.



Presentación PlanDePrecios



CAL/Fundamentos 44

Crear el enlace entre Presentación yPrecioDelPlan.



PlanDePrecios

0..1 0..*

Presentación



CAL/Fundamentos 45

Una vez que ha seleccionado la presentación y elPlanDePrecios, 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

AsientoPresentacionNivelPrecio

1..*

0..*



CAL/Fundamentos 47

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



PlanDePrecios

0..1 0..*

Presentación


1..*

0..*

0..*0..1



CAL/Fundamentos 48



PlanDePrecios

0..1 0..*

Presentación


1..*

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ónentre particiones. Ud. puede deducir lasdependencias evaluando las asociaciones.

Una clase está asociada con otra claseporque existe alguna forma decomunicación entre ellas. Los objetos deuna clase podrían consultar por información

de otra clase. P.e. El AsientoPresentaciónpodría pedir a Asiento el detalle de susubicaciones para imprimir en el boleto.

Particionar Dependencias



CAL/Fundamentos 51

Una forma de hallar la dirección de lasdependencias es buscas la dirección de

la comunicación entre los objetos. Enlos diagramas de secuencia ycolaboración se ha documentado la

forma que los objetos conversan.




CAL/Fundamentos 52

En el siguiente diagrama. Busque losdiagramas de interacción donde los dos

tipos de objetos se comunican. Ver si laflecha de evento va en una soladirección o en ambas. La(s)

dirección(es) de la flecha de evento ledirá la dirección de la dependencia.




CAL/Fundamentos 53

Vea el Subsistema Gestión de Eventosy el subsistema Gestión de

Facilidades. Existen tres asociacionespara examinar entre ellas.




CAL/Fundamentos 54

Particionar DependenciasEvento

10..*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 de

facilidades



CAL/Fundamentos 55

Encontrar los diagramas de secuencia ocolaboración que muestren la

comunicación de los objetos asociados. Aquí tenemos dos diagramas desecuencia que contienen los objetos

asociados. Por simplicidad se hacombinado en un solo diagrama connotas en ambos lados.




CAL/Fundamentos 56

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




CAL/Fundamentos 57

Actualice el diagrama de paquetespara indicar la dirección de la

dependencia.




CAL/Fundamentos 58

Dependencia paquetes


Evento 10..* Auditorio

1

1

PlanPisoAuditorio

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 deEventos

<<subsystem>>

Gestion de

Facilidades

<<subsystem>>



CAL/Fundamentos 59

Dependencia funcional. Una dependenciapuede existir entre una función y una clase u

objeto. Por ejemplo, el modelo de objetos ledice que las presentaciones deben formarparte de un evento (composición). Para crearun objeto presentación debería invocar el

objeto evento, pedir que cree una nuevapresentación y agregar el nuevo objetopresentació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 depresentaciones. Pero gestión depresentaciones depende, para hacer el

trabajo, del objeto evento que seencuentra en Gestión de Eventos




CAL/Fundamentos 61

Dependencia de tiempo. Otra forma deidentificar dependencias es determinar cualobjeto debe existir primero. Por ejemplo, en

el subsistema Poner Precios no hayinteracción de objeto que pudiera decirleexplícitamente en que dirección dibujar ladependencia. Tanto el objeto presentación

como el objeto PlanDePrecio han de existirantes que el subsistema de poner preciospueda hacer su trabajo.




CAL/Fundamentos 62

Dependencia entre particiones


Poner precios aPresentació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 proporcionauna división del sistema completo enunidades cohesivas de trabajo. En las

aplicaciones culminadas estas unidades sepueden combinar para soportar diferentesflujos de trabajo (workflows) o deberes. Elparticionamiento de dominio también fija la

fase de particionamiento arquitectural puescada tipo de trabajo o funcionalidad podríaimplicar una solución arquitectural diferente.



¿cómo dividiría el particionamiento dedominio? Debe primero asignar cada

caso de uso y cada clase de susmodelos de análisis a una partición dedominio y todas las asociaciones del

modelo de objetos deben preservarse.Nada debe perderse en la transición delanálisis al diseño.

Resumen

sesion 6_3 diseño - particionamiento de dominio

Documents