Pues ya está empezada la grabación. Vale, os dije la semana pasada
efectivamente que preparara las preguntas que tuvierais, lo cual creo que
es Guillermo el que dice que tiene una serie de dudas. Es normal porque el
hacer la práctica se deja para el final, me parece que es el día 13 el
plazo para presentarla y entonces cuando surgen todas las dudas. Y lo mismo
pasará con el trabajo final. Vamos a ver, he notado que hay una anotación
con respecto a la resolución de años anteriores para el usuario a clase
con los resultados. A ver, no sé a qué se refiere respecto al... Entiendo
que es al resultado que busca el actor. En el caso de uso, ¿es así?
Bueno, vamos a ver. Hay que tener bastante cuidado aquí con el significado
de las palabras y cómo lo estamos utilizando. Porque digamos que yo
intento tener ese cuidado, pero claro, es posible que... A veces se me
escape alguna cosa. Significa cómo se está describiendo el funcionamiento
y el funcionamiento ese que se describe puede ser radicalmente, digamos,
desviado. La cuestión que estoy diciendo siempre es que hay un actor que
sin conocer nada de lo que... Está funcionando por... Por dentro en el
sistema. Ya indico que aquí en medio está la interfaz de usuario y esta
interfaz de usuario no hace nada, nada más que presentar o formatear,
organizar la información, pero esa información, digamos, lo así, esos
objetos que está manejando aquí dentro como código dentro de la U no
tienen nada que ver. El valor de la información sí es la misma. Pero los
objetos que hay aquí y está manejando tienen que ser totalmente
diferentes a lo que hay dentro del sistema, sea conceptual lo que estamos
representando aquí o sea el código lo que estemos representando aquí.
Esos objetos, insisto, conceptuales o de código no son para nada los
mismos que se están manejando aquí, aunque la información sí que
coincida. O sea, los valores de ese... La información sí que coincida,
pero no su tipo ni la clase a la que pertenecen, etcétera, etcétera.
Dicho esto, que ya lo he repetido varias veces, aunque es un repaso
conceptual, lo único que puede conocer desde el punto de vista conceptual
del sistema y del funcionamiento del sistema es que el actor quiere algo.
Así que solo puede tener relación con algo que está representando el
resultado buscado por el actor. Eso es lo único que puede conocer ni
conceptualmente, o sea, conceptualmente, mejor dicho, lo que puede conocer
del sistema que está manejando. Así que, digamos, solo puede haber
interrelación entre... El actor y ese resultado que está buscando. Ahora,
al reflejar esto, esto que estoy contando, en el modelo de dominio, el
actor buscará o iniciará, que es como estamos representando esa
relación, algo que estamos llamando resultado buscado por el actor en el
funcionamiento del caso de uso. Ese contendrá... Una serie de valores, de
información. Y a su vez nosotros podremos esto organizarlo, aunque sea
totalmente irrelevante en cómo se organice, con respecto al actor. Sea
irrelevante cómo está organizado. Pero nosotros conceptualmente tenemos
que organizar para poderla manejar y construir ese resultado. Nosotros no,
lo construye el sistema. Pero nosotros al representarlo en el modelo de
dominio, que es una representación conceptual de la información
organizada en unas determinadas estructuras, pues esa estructura la podemos
poner como más nos convenga. Por ejemplo, esto está formado por 1N
componentes que forman una colección correspondiente a... Digo en general,
que esto es un caso genérico. Y puede darse como en procesar venta, que la
venta esté formado por una colección y por eso este... Ahora, la pregunta
va, que si la anotación correspondiente a que el actor inicia, no
construye, porque no es él el que construye. Pero inicia, digamos, la
búsqueda o la confección, la construcción de ese resultado que está
buscando el actor. Y la anotación es que un actor, porque estamos
suponiendo un único usuario de la aplicación que está buscando un
resultado, inicia la construcción de un resultado. Si ese resultado está
compuesto por... Varios elementos, pues a su vez ese resultado que tendrá
una información o no, simplemente está compuesto o contiene una
colección de distintos ítems que se van a ir formando en la
construcción. Pero en principio, el actor lo que busca es un único
elemento, objeto conceptual que... Constituye el resultado. ¿Me he
explicado? Vale, pero es que una orden es una cosa distinta... No, vale.
Explicando que una orden dentro de un caso de uso es distinto al caso de
uso global. Yo me refiero que en el caso de uso, aunque haya varias
órdenes, digámoslo así, dentro del caso de uso, o una orden sería
agregar producto a la venta, ¿vale? Y eso se puede repetir varias veces,
pero eso no quiere decir que esté buscando n resultados. Él busca uno,
que es la venta, y es la cardinalidad, debería ser uno, entiendo. A no ser
que eso lo estemos representando directamente como la colección. Y en ese
caso, si el resultado fuera una colección, pues efectivamente son varios
ítems lo que está buscando. Y al ser varios ítems, ese objeto buscado
como representante de ese resultado del que está buscando el actor, pues
sí, en ese caso, muy particular, podría ser varios. ¿Vale? Pero en
general, lo que busca es uno. No sé si me explico. Vale. Pues eso es.
¿Alguna cuestión? Sí. Para evitar, digamos, malentendidos, a mí, en el
ámbito del modelo de dominio, que es modelado conceptual, no me gusta
utilizar la palabra clase. Sino objeto conceptual, aunque entiendo
perfectamente cuando se usa así. Y bien entendido también que estamos en
el ámbito del modelo de dominio y del modelado conceptual. Pero como clase
tiene una cercanía para mí muy próxima a lo que es el código, una clase
de código, ¿no? Sí. Es demasiado cercana y para, digamos, impedir la
tentación de estar pensando en el código en el modelado conceptual, por
eso prefiero utilizar objeto conceptual en lugar de clase. Vale. La
pregunta es, ¿un atributo de una clase obtiene de otra clase? Bueno, vamos
a ver. En parte, eso hace referencia. Lo de que un objeto conceptual
obtiene su atributo de otro objeto conceptual, lo de obtener ya es una
acción. Una acción que significa una responsabilidad o un método en el
objeto invocante. Bien. Que en el ámbito del modelado de dominio, que no
es código y, por tanto, no debemos atribuirle ningún método, ninguna
responsabilidad. Y, por tanto, y por ese motivo, es por lo que las
relaciones no pueden significar ninguna acción o nada que se pueda
convertir en una acción. Cuando lo traduzcamos a código, en un método.
Así que las relaciones son siempre de contiene, indicando que un objeto
está contenido, o sea, que es un miembro de otro objeto. Cuando se ponen
en el modelo de dominio, vale, quiero ser bien claro. Cuando un miembro
componente de otro objeto se representa en el modelo de dominio, en
general, no se representa como atributo del objeto contenedor, sino que se
pone en la relación contiene y el atributo no se pone. Hay un caso
especial que habréis visto y es en el. Especificación del producto que
hay un atributo que está relacionado con el objeto conceptual, que es un
nuevo objeto que tiene un atributo que precisamente es el valor que tomará
este. En el modelado conceptual no se ponen tipos ninguno. Y si en los
ejemplos. Que expongo aparece algún tipo es por del modelo de dominio. Es
porque quiero llamar la atención sobre una determinada estructura que voy
a dar o llamar la atención sobre alguna cuestión que quiero resaltar,
como por ejemplo lo que expliqué. No sé si hace una. Dos tutorías
respecto al identificador del producto cuyo tipo es precisamente artículo
y de que es una manera para desacoplar el funcionamiento de este objeto que
va a ser una clase con el que vamos a trabajar de manera intensiva en el
funcionamiento del caso de uso para desacoplarlo. Desacoplarlo.
Precisamente el producto y de de su tipo. Y no haya un una obligación de
cambiar el funcionamiento de todo el caso de uso a la hora de que nosotros
pues cambiemos el el el tipo del identificador. En parte bueno eso ya lo
expliqué el por qué repetir producto y de. Repetirlo con el el el objeto
o clase artículo y de de manera que tomara el el valor en este caso tal
como está puesto en este en esta presentación se llamaría la clase o
objeto conceptual producto. Producto. Y de. Vale y aquí estaría el valor.
Del de ese identificador. Que ya puede ser el tipo que nosotros queramos un
un string puede ser un entero puede ser lo que nosotros queramos porque
este atributo va a ser siempre de la clase producto y de. Y demás de esta
manera no cambiamos todo el funcionamiento del caso de uso cuando queramos
cambiar la forma de de. Vale. Entonces voy a terminar de contestar la otra
pregunta. Vale sigo con la otra pregunta si un atributo de una clase se
obtiene de otra clase es necesario indicar primero no no se debe
representar relaciones de obtiene de otro sitio. Si es verdad. A ver si
está aquí. Bien. La primera pregunta. El actor. Inicia. Un único
resultado. Segunda pregunta. Aquí el. Lo de obtener. Un un objeto.
Obtiene. Otro objeto. La. Si utilizamos esta analogía de este modelo de
dominio y el de procesar venta. La venta. Contiene. Una colección de.
Línea de venta o ítems vendidos donde el actor aporta la cantidad. Y el
resto de la información que va a ser la descripción. El precio. También
va a incorporarse. En el ítem vendido. Hasta ahora se entiende lo que
estoy diciendo. Hay que tener mucho cuidado. Porque. Especificación del
producto. El el ítem de esta colección. Que se vaya a utilizar. No sé.
No se va a incorporar. No va a ser un miembro. No va a tener el mismo tipo.
Especificación del producto en el ítem vendido o línea de venta vendido.
O sea. Esta. Instancia de esta clase. No se va a meter aquí como
componente de ninguna manera. En cualquier caso. Este no obtiene. De aquí.
Vamos a tener que pensar en el mecanismo de funcionamiento del código. Y
va a ser. El controlador. Y de eso quería hablar en esta tutoría. El
controlador. El que se va a encargar. De recoger esta información. Y.
Incó e incorporarla. En el elemento. Este de línea de venta. Junto con la
cantidad. Pues va a incorporar en la descripción. El precio. El ID del
artículo. En este elemento. Este. Procedencia. Que no obtener de. Que hay
un matiz. Pequeño. Pero lo hay. Y es importante. Se. Representa. Por. Esta
relación. Es decir. Esta relación está diciendo que el contenido de
línea de venta. Viene descrito. Por un. Elemento de esta colección. Un
elemento. Pero. Que quede bien claro. Que. El tipo. Este. No se enchufa.
Como. Atributo. O miembro. De este elemento. Si no es la información. La
que se recoge. De acuerdo. No. El tipo que hay aquí. Dentro. Como
contenido de línea de venta. No es especificación del producto. No. Y en
general no lo va a ser. Y hay que tener cuidado con eso. Es el registro
venta. El que se encarga de recogerla. O sea. El registro venta. En este
caso. El controlador. Y para eso sirve. Ese es su rol funcional. En el
modelo conceptual del modelo de dominio. Y luego cuando nos pongamos. A.
Construir. El funcionamiento con el código. Será. También. El
controlador. Del caso de uso. El que se va a encargar. De hacer. Esas
operaciones. Así que. En respuesta. A la pregunta. Una clase. No. Obtiene.
Información. De otra clase. El atributo. O. La procedencia. Del atributo.
Se utiliza. La descripción. O. Una relación. De. Descrito. Por.
Atributos. Así que. No se puede decir. Que está contenido. Vale. Cuando.
Por ejemplo. Catálogo de productos. Contiene. Efectivamente. Y tendrá un
atributo. Que será. El. La colección. Que contiene. Pero no se pone
aquí. Como atributo. En catálogo de productos. No se pone. El atributo. Y
se pone. La relación. Contiene. Pero. En el caso. De. Item. Venta. Que se
tiene. Que construir. No contiene. Uno. De estos elementos. Porque no
sabemos. Cuál. Todavía. Pero sí. Ponemos. Que. Su. Contenido. Esa. Esa
información. Procede. De. Está. Descrita. Por. Ese. Elemento. Que. Vamos
a. Va a ser. El que vamos. A. Respondido a esa pregunta. Guillermo. Vale
la. No entiendo muy bien. La. La plantilla. La pongo. En war bien Pdf me
parece que es. Pero. Pero ese es como plantilla. Lo. un programa, cualquier
aplicación o plataforma que permita formatear un documento. Me da lo
mismo. Ahora, lo que se reciba en el curso virtual, en el depósito, tiene
que ser algo que pueda leer, o en formato del Open Office, o en fin, alguno
de esos formatos que yo pueda leer. Por eso, lo preferible es un PDF, que
si se puede generar un PDF, pues se puede editar con lo que cada uno estime
más conveniente, y la plantilla es una simple referencia para poner, hay
unos datos en la carátula, y luego responder ordenadamente a cada una de
las preguntas, tanto de la PEC como del trabajo final. Mientras, digamos,
el documento se edite con lo que sea. Y luego se genere un PDF o un doc,
alguno de estos, básicamente son estos dos formatos los que puedo leer en
un, y los tutores, por supuesto, y sean legibles desde cualquiera de estos
dos elementos, aunque insisto, yo prefiero el PDF porque precisamente en el
PDF, pues ya ahí incorporo directamente las propuestas de mejora de las
respuestas que se han realizado. Pues mientras sea en uno de estos, pues se
puede editar en lo que sea. Vale, vale. Había otra pregunta aquí de, creo
que es Jesús. Vale, una duda en el formato de la PEC. Aparte del diagrama,
he añadido una pequeña explicación. Ya, bueno, es que en bastantes años
anteriores se hacía, o se hace, hay una costumbre bastante generalizada de
poner un diagrama cuya interpretación es la que es según la sintaxis de
UML y lo que significa, que se pone aquí, y luego se pone una explicación
diciendo, no, porque esto significa tal, y entonces hace esto, y entonces
lo que sea. Vale. Todo eso, pues, digamos, que si lo que se está
representando en este diagrama significa una cosa por la sintaxis UML y no
hay más desviación, y aquí se reinterpreta de otra manera. No puedo
hacer caso a lo que se está reinterpretando aquí, porque en primer lugar,
hasta cierto punto, está contradiciendo lo que se expresa en el diagrama,
que es lo que se pide. Entonces, reinterpretaciones de un diagrama para
intentarme convencer que donde digo pulpo estoy diciendo animal de
compañía, eso es lo que estoy diciendo que no es aceptable. Lo que...
Único aceptable es lo que indica, o sea, lo único que se está valorando
es lo que indica la semántica según la sintaxis UML, lo que se está
representando en el diagrama. Si en el diagrama no queda claro, es que el
diagrama no está bien. Entonces, huelgan todas las demás explicaciones.
No sé si me explico. Y para... Y para volverme a decir exactamente lo
mismo que se dice en el diagrama, pues también huelga esa explicación.
Entonces, no hace falta rellenar más. No es que se valore negativamente,
es que simplemente, en general, no hago caso de ello. Vale, creo que era
Jesús quien me preguntaba esto. ¿Está aclarado? Vale. Por eso, más que
hacer hincapié en dar una explicación sobre el diagrama, yo creo que vale
muchísimo la pena hacer hincapié en que el diagrama represente
exactamente lo que estamos intentando transmitir, o lo que se dice. Y
ajustarse efectivamente. O sea, no es ser estricto en cómo se
representa... En la versión 2.x de UML, en un diagrama, cómo se
representa una determinada cosa. No soy estricto en eso. Simplemente, lo
que sí soy estricto es que si en un diagrama se está representando una
cosa y eso está significando, sin lugar a dudas, algo... Un significado
X... No acepto explicaciones que me digan matizaciones de ese X o que ese X
funcione de otra manera distinta. Lo que se pone en el diagrama es lo que
es, y eso es la respuesta. Y a esa respuesta me atengo. ¿Vale? Vale,
¿alguna preguntilla más respecto a lo que llevamos diciendo? Bien, vamos
a retomar. Cuando hacíamos... Todavía seguimos en el modelo... Y...
Digamos, quería cerrar un poco más esto, no solo por la importancia, que
tiene importancia como cualquier otro elemento del análisis y del
desarrollo para llegar a nuestro diseño. Pero quería llegar a empezar a
construir el diseño. Antes de meterme en la explicación de... ¿Cuándo
usar? Que ya empecé la semana pasada. ¿Cuándo usar o no los catálogos,
los significados o el significado que tiene el catálogo y su uso? Quería,
digamos, retomar un poquito cómo hacer el modelo de dominio. A ver... Ya
he dicho muchas veces que cuando pensemos... En el desarrollo de un paquete
de software, sea una aplicación en sí, sea una parte, sea lo que sea,
aunque una vez pasado esa fase de inicio, una vez que nos centramos en los
casos de uso y en el desarrollo de cada uno de esos casos de uso, que
necesariamente tendremos que estar pendientes... Y construyendo.
Construyendo quiere decir concibiendo, o sea, pensando, creándonos un
modelo tanto del caso de uso como del funcionamiento de ese caso de uso en
el ámbito general de lo que estamos construyendo. Porque ese caso de uso
necesariamente va a estar funcionando. Trabajar. Con los otros casos... Con
los otros casos de uso y con la aplicación en general. Y tenemos que
pensar desde el principio y con cada caso de uso en un esquema general,
general global, y luego dentro de cada caso de uso igual. Un esquema lineal
jerarquizado del funcionamiento. Esto, digamos, gráficamente quiere
decir... Lo siguiente. El actor va a iniciar una aplicación y habrá algo,
en este caso es el sistema operativo, el que está pendiente de la
iniciación, el arranque de la aplicación del programa dentro del entorno,
de los recursos del sistema y del funcionamiento de distintas aplicaciones.
Concurrentemente, en fin, como sea. Una vez que está arrancado y se crean
unos determinados elementos que están en funcionamiento, esta jerarquía
se podría representar de una forma, digamos, arbórea. Pues tendrá varias
opciones de uso, que serían los distintos casos de uso. O dependiendo,
pues lo puede arrancar y una vez que está arrancada, en realidad, pues el
mismo usuario u otro usuario, que lo fuera una vez que está arrancada la
aplicación, que iniciara una sesión. Pues a un controlador global. Pero
le pide el inicio de sesión, que será un único elemento, un único
objeto, el que está a la escucha. A ver si esto me pinta donde me tiene
que pintar. Bueno, pues no me pinta. El que esté a la escucha de lo que
quiere el usuario. Prepara el perfil del usuario que se quiere dar de alta
en esa sesión, construye los objetos que tenga que construir y pasa el
testigo a un objeto, es decir, delega el control en otro objeto a partir de
ese punto, de entonces, es ese objeto. El que está a la escucha y
atendiendo, qué opción, qué opción de estas está queriendo realizar,
que pueden ser distintos casos de uso dentro del perfil de utilización de
ese usuario dentro de esa sesión, qué distintas opciones o casos de uso
dispone de ellos. Si ese mismo... Si ese mismo actor solicita, y a quién
se lo solicita, pues a ese controlador de ese nivel jerarquizado del
funcionamiento, ese controlador que es el único que está a la escucha, le
solicita ese caso de uso, pues este controlador hará... determinadas cosas
para dejarlo preparado y delegar a su vez en otro controlador del caso de
uso que ya va a estar atendiendo a las peticiones del usuario. Aquí en
medio está la interfaz de usuario, pero en el funcionamiento es un
esquema... Es un esquema jerarquizado en el sentido de que en cada punto de
la jerarquía del funcionamiento, sólo hay un controlador que está a la
escucha, sólo uno, el que está activo. No hay nadie más que esté
atendiendo a las peticiones a través de la interfaz de usuario. Sólo uno
atiende. Y cuando yo le doy la opción que quiero, entonces delega en sólo
un controlador, que es el que atiende en ese momento, a partir de entonces,
a las peticiones de usuario. Órdenes como decía vuestro compañero
anteriormente. ¿Qué sucede en un caso de uso, por ejemplo, de procesar
venta? Y en realidad... Lo de lineal se refiere a que no hay simultaneidad
en los controladores del caso de uso, perdón, no hay simultaneidad en los
controladores y esto sigue un funcionamiento de una sola rama. No hay
concurrencia en cuanto a las ramas que están atendiendo a la interfaz de
usuario. Y no hay observadores, no hay registros de eventos, que puede
haberlos, pero en nuestra concepción de cómo funciona cada caso de uso,
tanto en el modelo de dominio como luego en la implementación del
funcionamiento con el código en el diseño detallado, no va a... No vamos
a representar esas concurrencias o esas simultaneidades de que haya varios
controladores atendiendo a los eventos que se puedan producir. Que esto nos
resta generalidad para construir el funcionamiento de esta manera que acabo
de decir, es decir, habiendo distintos observadores. Que reciben los
eventos del usuario y según se registren en un determinado objeto, pues se
ejecuten unas tareas o se ejecuten otras. Eso se puede hacer incluso
pensando y organizando el funcionamiento tal como lo estamos organizando.
Así que es importante que penséis que el funcionamiento es lineal en el
sentido de que... Que no hay concurrencia y solo hay un objeto activo en
cada instante de la línea temporal, solo hay uno funcionando a la vez y
que no hay concurrencia y que todo esto se canaliza a través de un único
controlador. Por eso la palabra controlador no solo aparece en el código,
sino que aparece también en el... A ver si... A ver si lo encuentro donde
estaba, porque ya son muchos ficheros. Aparece la palabra controlador en el
modelo de dominio porque es imprescindible tener un objeto cuyo rol
funcional, conceptual, sea precisamente organizar cuál es la secuencia de
acciones que se han escrito en la escritura del caso. En el caso de uso,
¿cuál es ese orden? Y es el que se va a encargar de construir, y por eso
esta relación, el resultado buscado por el actor. Ese es el rol conceptual
en el modelo de dominio del controlador. Y por eso es imprescindible poner
un objeto controlador. Así que, en la pregunta de antes... Si algún
objeto va a obtener información de otro sitio, va a ser el controlador el
que va a obtener lo que necesite para enchufárselo, para construir ese
resultado que es el que busca el actor. Entonces, eso hay que tenerlo bien
claro. Que hay una única línea de funcionamiento en el tiempo. Que en
cada nivel jerárquico del funcionamiento, es un controlador el único, un
único controlador el que está atendiendo a los eventos del actor. Y, a su
vez, que hay una jerarquía porque cada vez que entra otro nivel del
funcionamiento, el controlador anterior... Prepara la información, los
objetos, las clases o lo que sea, que va a necesitar el siguiente nivel de
funcionamiento en la jerarquía y delega en el siguiente controlador de ese
nivel de funcionamiento en la jerarquía. En procesar venta... Hacemos a lo
mismo. Lo primero, como os he dicho, según esa plantilla que os propongo
del modelo de dominio. Lo primero, a ver qué es lo que está buscando como
resultado el actor principal que maneja el sistema, qué información tiene
que contener, vale, pues va... En el caso de... En el caso de procesar
carga al buque, pues el resultado de la carga va a ser una serie de datos,
la fecha, la hora, otra serie de información que provendrá de otros lados
y que esto no aparece aquí, sino que está descrito por... Vendrá de una
información de otro lado, lo que llamamos el modelo de datos o lo que
llamo yo en la plantilla es el modelo de datos. O sea, que esto no aparece
aquí. Y en cada depósito o tanque del buque que se está cargando, pues
la cantidad que se carga, que todo esto lo está... Eso lo está aportando
el actor principal. Habrá otra información que será la especificación
del producto y además eso... Cada uno de estos ítems del producto cargado
en un tanque contiene pues una serie de resultados de la maniobra que
resulta que se los da así en bruto básicamente, se los da el actor. Se
los traslada el actor básicamente porque estamos eliminando todas las
interacciones con el hardware y que recoja todos esos datos de la maniobra
de manera automática para simplificar el... El caso de uso, el
funcionamiento del caso de uso. De manera que lo primero determinar cuál
es la información que estamos buscando como resultado de la operación o
del uso del actor, del sistema. Hasta aquí espero que se haya entendido
bien. Ahora, lo siguiente sería, a ver, esta información, ¿de dónde la
voy a sacar? Evidentemente la va a sacar el actor. Digo, el controlador del
caso de uso para trasladarla o inyectarla o construir ese resultado. Pero,
¿de dónde se va a sacar? Vale. Pues, como os decía antes, hay que tener,
digamos, en mente cuál es el funcionamiento... Lineal, o sea, unifilar y
jerarquizado, escalonado, por delegación de toda la aplicación en sí.
Como os decía, voy a ver si esto lo puedo agrandar un poco. Vosotros me
diréis si se ve mejor o peor. Supongamos que el actor... No sé si esto
escribe bien. Bueno, pues ya... El actor, supongamos que una vez arrancada
la aplicación de punto de venta, es decir, la caja, lo que hace es abrir
una sesión donde se identifica y lo prepara para las... Y se prepara para
las distintas acciones a las que puede estar... Estar atendiendo a la caja.
La cuestión es que el inicio, antes de que se produzca una venta, el
inicio, y estamos antes del caso de uso, es que la caja se prepare para
recibir las ventas. No sé si aquí me está escribiendo... No, no lo
recoge. Entonces, la orden sería preparar... El previo al inicio del caso
de uso de procesar una venta sería preparar la caja para las ventas. Lo
que hace el controlador de turno en ese momento es crear el catálogo de
precios de productos, puesto que es la información que se va a... A
manejar. La información que se va a necesitar manejar para construir el...
El resultado buscado por el actor en cada una de las ventas. ¿Por qué
hago esto y no cualquier otra cosa? ¿Vosotros qué creéis? Bueno, os voy
a hacer la pregunta de otra manera. O lo voy a explicar de otra manera. Una
vez que veamos en dónde estamos, lo voy a poner otra vez a dimensión
normal, porque es que si no, no me deja escribir normalmente. Yo aquí le
estoy pidiendo que se prepara para ventas. Ahí es donde se incluye la
inteligencia del funcionamiento del sistema. ¿Por qué? Si yo quiero
preparar el sistema para que recoja las ventas, sé el producto, el
resultado que voy a necesitar obtener en cada una de esas ventas. Y para
eso es para lo que me estoy construyendo... A ver si no... Y para eso es
para lo que me estoy construyendo el modelo de dominio. Este. Yo sé cuál
es el resultado. Yo sé, no. Quiero decir, el sistema, por la construcción
y por cómo construyo el funcionamiento en el sistema, debe saber que el
resultado que voy a buscar es este. Y que en este resultado que el actor
busca, por el hecho del caso de uso de utilizar el sistema para eso, va a
necesitar el listado de precios, que es una colección... de los precios de
los productos. Para manejar toda esa colección, no de una manera
deslavazada, un elemento a un elemento, necesito un contenedor que contenga
y maneje todos los elementos de esa colección que voy a necesitar para
construir este elemento. Así que, el controlador, del caso de uso, va a
necesitar acceso a ese manejador para poder acceder a su vez al elemento
que necesite para construir este resultado. Pues, una vez entendido eso, y
eso es importantísimo que lo entendáis, vamos a la implementación para
que también lo veáis. Por lo que os acabo de decir, antes, efectivamente,
cuando yo le digo que quiero ventas, como sé todo eso o el funcionamiento
del punto de venta debe saber todo eso, lo que tiene que hacer es crear el
catálogo de precios de productos bueno, el catálogo de precios de los
productos para que rellene todo su contenido con la colección y una vez
terminada la construcción de ese catálogo construye el controlador del
caso de uso y le pasa en su constructor precisamente el manejador de esa
colección, es decir, el catálogo. Y a partir de ahí el control pasa al
controlador de registro ventas, al controlador del caso de uso procesar
venta. Y éste no hace nada ya hasta que no termine de trabajar éste. Pero
el controlador del caso de uso resulta que tiene ya toda la información
necesaria para atender a la fabricación, construcción, elaboración como
lo queréis llamar, de ese resultado que está buscando el actor en ese
caso de uso. Quiere esto decir que perdón eh Quiere esto decir que el
controlador de nivel superior cuando recibe una orden digámoslo así, un
mensaje por parte del actor para determinar eh un determinado caso de uso
lo que hace es acceder a los objetos que vaya a necesitar y dicho de una
manera coloquial lo que crea es una oficinita aislada aislada quiere decir
que tiene ahí todos los componentes todos los objetos todas las clases
desvinculados de donde puedan proceder es decir copias de ellos de manera
que las modificaciones que se hagan aquí no se están modificando de
manera global aunque podemos conseguir hacerlo pero en principio esto son
copias aisladas que se construyen en esta oficina que a partir de aquí es
la que atiende directamente todas las interacciones con el actor y que se
encarga de ir construyendo el resultado por eso os decía la semana pasada
lo que sucede en Las Vegas se queda en Las Vegas, pues aquí lo mismo una
vez que entramos en el caso de uso entra en vigor el controlador del caso
de uso que es único y ese controlador del caso de uso tiene todas las
herramientas que son los objetos o la información con la estructura
específica para que sirvan a la construcción de este resultado y ese
controlador que tiene acceso a todo ese material es el que se encarga de
construir ese resultado establecer además todo lo que os he dicho antes
esa secuencia de pasos que hemos escrito en la escritura del caso de uso y
eso es aislado cuando termina esto devolverá el control al controlador de
nivel superior y se seguirá como se tenga que seguir haciendo lo que se
tenga que hacer pero esto está aislado y protegido de la modificación de
cualquiera de los otros elementos así que otra cosa en la que hay que
fijarse bueno ya hablaríamos del de los de los catálogos no sólo como
contenedores de una determinada colección de información en la que
algunos de sus elementos los vamos a necesitar para construir ese resultado
que efectivamente pues como elemento de información el catálogo que
contiene la colección para que pueda manejarlo va a estar incluida es
decir se le incluye se le pasa como una copia de él se le pasa como
argumento al constructor del controlador del caso de uso como veis a ver si
no sé dónde está esa presentación como os dije el otro día hay que
también pensar el código sobre el que estamos pensando el de el que está
delimitado dentro de la capa del negocio de la aplicación que estamos
construyendo no sólo del caso de uso el caso de uso el código este está
ahí metido pero también forma parte del caso de uso la parte de la
interfaz de usuario al final en una aplicación no distingue entre partes
ni nada de eso aunque pueda tener una estructura modular en distintos
ficheros o como sea pero la cuestión es que es un único código ahora
nosotros vamos a separar porque además el funcionamiento tiene que estar
totalmente separado de lo que es la interfaz de usuario y de lo que es la
parte de acceso a datos y en lo que nos estamos fijando aquí es en la
parte del negocio la funcionalidad esencial bien lo que estoy diciendo es
que esto los objetos o en el código las clases se organizarán en
distintos paquetes o módulos o componentes de lo que es una arquitectura
vale y como dije la semana pasada pues seguramente el tratamiento y el
manejo de las cuestiones sobre los productos que quiere decir los precios
pero también el catálogo de proveedores de productos para compras o el
catálogo de piezas componentes de un determinado producto que se vende en
fin todos los objetos y clases dedicadas a manejar este tipo de
información estarán en el paquete productos y por tanto el catálogo de
precios que contiene la colección de precios de los productos este
catálogo estará dentro de este pues vale como estáis observando el
controlador de rango superior está accediendo sin ninguna cortapisa a este
módulo de la arquitectura de los productos y está pillando un elemento
una copia del catálogo de productos se está invocando la creación de una
instancia del catálogo de productos o sea que es que el controlador de
nivel anterior tiene que tener acceso a el paquete al módulo por muy
independiente que lo estamos haciendo os acordáis que estamos diciendo no
no es que todos estos elementos deben tener lo que hay aquí dentro el
mínimo acoplamiento bueno dentro de este paquete de productos sus
elementos tienen que tener el mínimo acoplamiento entre sí y a su vez
este tiene que tener el mínimo acoplamiento con otros paquetes y y el
controlador accede a este paquete lo cual significará que o bien es de el
ámbito del gobierno que tiene acceso a todo el mundo o bien es de un nivel
jerarquizado inferior al que se le ha tenido que dar acceso para que pueda
acceder a este módulo este componente este paquete para que pueda acceder
a la creación de una instancia de la clase catálogo del precio de
productos vale la crea pero para crearla evidentemente está vacía no
tiene la información ni los elementos en la colección vacía que podría
contener entonces eso no se crea la información por arte de magia hemos
dicho que queremos mantener aislado y separado el almacén donde se guardan
los datos de una manera genérica y que dentro de el ámbito de el negocio
no debemos preocuparnos de cómo se almacenan la información que vamos a
manejar de hecho el, el nombre del producto el precio del producto estará
organizado dentro de si esto es una base de datos en una estructura que
desconocemos y que tampoco nos importa conocer en absoluto pero tendrá su
fachada de manera que mediante un determinado protocolo se le puede pedir
información y que nos la dé en un determinado formato como puede ser el
protocolo o el lenguaje SQL y a esto fachada específica de esta base de
datos se comunicará con ella esta fachada específica para esta fachada de
la parte de acceso a los datos y esta fachada que utilizará sentencias SQL
para comunicarse con esta fachada pues obtendrá una información que le
pasará a un adaptador un adaptador que traducirá esa información en un
formato coherente con el que provee la fachada específica de la base de
datos se la se la asigna a este adaptador y este adaptador transforma esa
información en una estructura que ya sí ya es conocida especificación
spec del producto en una estructura que ya sí es conocida dentro de el
código que estamos construyendo en la capa del negocio vale es decir que
nosotros aquí consideramos que construimos captamos porque este
controlador tiene acceso a este módulo y capta un catálogo el catálogo
tiene un mecanismo que accede al exterior a través de un adaptador para
construir el contenido de esa colección todo esto es funcionamiento de
código puro y duro no es nada conceptual no es nada del modelo de dominio
es todo diseño código puro y duro y este adaptador lo que hará es a
través de estas fachadas obtener la información del almacén y
transformarla en objetos utilizados dentro de el negocio y construye esa
colección o el contenido los elementos de esa colección y el contenido de
cada uno de ellos y una vez que ya está completado ese catálogo de
productos pues entonces se construye el registro el controlador del caso de
uso al que vamos a acceder e insisto se le aporta una copia de ese
catálogo de ese contenedor y manejador de la colección de información al
al controlador del caso de uso y a partir de aquí delega el controlador de
nivel superior delega en este controlador y ya a partir de aquí ya a
través de la interfaz de usuario las órdenes los eventos llegan a este
controlador hasta que se termine y devuelva este en todo este montaje
kiosco que nos hemos montado he dicho en alguna de las respuestas que todos
estos objetos que estamos manejando para construir el funcionamiento sean
conceptuales o sean del diseño en el código son aparte de esa
independencia que tiene que ver con el almacenamiento con la interfaz de
usuario entre unos objetos y otros entre unos módulos o componentes de la
arquitectura y otros etcétera etcétera que están todos en la memoria
vale una de las cuestiones que he explicado en las respuestas en los foros
es a nadie se le ocurre que si esta base de datos es de 5000 cuando
construimos este catálogo que maneja la colección pues cargue a través
de este adaptador que es del tipo interfaz etcétera etcétera que cargue
los 5000 elementos de esa colección para mantenerlos en memoria vale pues
es que este mismo procedimiento de acceso indirecto desacoplado que eso es
lo fundamental que está desacoplado mediante este mecanismo que os acabo
de explicar es una parte fundamental que es una factoría de servicios que
es la que crea las interfaces pero eso es otra cuestión que ya hablaremos
más adelante tiene acceso a eso pero a nadie se le ocurre pensar que se
van a cargar los 5000 en la colección bien pues se pueden cargar unos
pocos como se explica en la segunda en la última parte del libro y hacer
una carga temprana o una carga intensa de esos contenidos se puede incluir
en el código de este catálogo y este catálogo insisto su rol funcional
es tanto de contenedor de la colección no los elementos lo que contiene es
la colección y es lo que trata la colección vale y pues su rol funcional
es la de contener y también lo llamo manejador porque es la que maneja
así que tiene los métodos para manejarla pues lo mismo que ponemos los
métodos para cargar lo que podíamos hacer en esos métodos para hacer
cualquier operación si no lo encuentra en el digamos los datos locales que
tiene en memoria si no encuentra un determinado elemento puede recurrir a
través de este adaptador a hacer la consulta en el exterior es decir
acceder a través del adaptador a la base de datos para obtener el elemento
que le pueda faltar etcétera de manera que aquí conceptualmente los
tenemos todos porque luego en el código podemos si no hay alguno en
memoria en ese momento a través de este adaptador que es un mecanismo
puramente software podemos acceder al almacén siempre desacoplado y
traernos el elemento el elemento cuya estructura su tipo no tiene nada que
ver aquí no hay esos objetos que estamos manejando aquí no existe
estructura especificación del producto aquí no existe especificación del
producto ni existe en la fachada de la base de datos ni existe en la
fachada de la parte de servicios técnicos del servicio de persistencia
existe únicamente aquí en el adaptador que traduce el resultado que ha
obtenido la fachada de acceso a la base de datos de la parte de servicios
técnicos lo traduce a este los elementos esta clase especificación del
producto ya si se conoce aquí dentro de los límites del negocio puede ser
muy enrevesado digamos este mecanismo pero si están enrevesados es
precisamente para no tener nunca que acceder directamente al sistema de
almacenamiento porque el sistema de almacenamiento sus responsabilidades no
son para nada las esenciales de las funcionalidades de los casos de usos o
del gobierno de la aplicación que estamos manejando y por eso tenemos que
desacoplarlos es decir aislarlo y qué forma hay de aislarlo aislarlo de
verdad a través de esta indirecciones es decir una interfaz y un adaptador
de ese tipo de la interfaz abstracta que tiene acceso a la fachada que a su
vez tiene acceso a la base de datos o al sistema de almacenamiento otra
cosita también de código puro y con eso ya estoy dando nociones respecto
a la implementación y el diseño detallado este no sólo el controlador
del caso de uso anterior no sólo tiene bien este es el catálogo de
precios y esto sería la la la colección vale este controlador no sólo
tiene acceso al catálogo de precios del producto sino que este catálogo
de precios del producto lo que hace es construir un adaptador primero pide
una interfaz y de esa interfaz obtiene un adaptador especializado para esta
fachada de la base de datos o del sistema de almacenamiento que estamos
utilizando externo es decir este catálogo de precios de producto tiene que
tener acceso a un constructor de esas interfaces abstractas y que a su vez
generan o producen el adaptador específico y especializado que necesita
para acceder resulta que a quien se lo está pidiendo se lo está pidiendo
como se ve en esta orden a una factoría de servicios esta factoría de
servicios resulta que tiene un carácter global es decir forma parte del
gobierno en realidad no está dentro de un paquete pero tiene una
visibilidad global y desde cualquier punto de un caso de uso esa oficina
aislada que había dicho que se formaba cuando se entra dentro de un caso
de uso desde cualquier punto del funcionamiento se puede acceder a ella
para que nos dé la interfaz o el adaptador especializado que nosotros
estemos necesitando y que en este caso nos da acceso al exterior no es
éste el que está accediendo al exterior no es éste el que se comunica
con el antecesor eso no es posible si un objeto crea a otro éste no se
puede comunicar con su padre eso no es así lo crea hace lo que tenga que
hacer cuando ha terminado éste sigue con su rutina por ese funcionamiento
unifilar que os he dicho anteriormente bien, ¿hay alguna pregunta en todo
esto? esto tiene repercusiones precisamente en cómo creamos el modelo de
dominio y por supuesto en cómo construimos el funcionamiento con el
código en el diseño detallado ¿se entiende o no se entiende? vale aunque
se diga ahora que se entiende porque es bastante de perugrullo cuando uno
se pone a trabajar y hacer, como es el caso el modelo de dominio y luego la
implementación del diseño es decir, el funcionamiento la implementación
del funcionamiento con el código empiezan a surgir todas esas preguntas
muchísimas preguntas y lo que se dice ahora que se entiende generalmente
es muy frecuente que no se vea tan claro no se deje de entender vale, por
lo que he dicho anteriormente por eso es por lo que el controlador de nivel
jerárquico anterior es el que está manejando ese catálogo de productos
que lo enchufará como digo como argumento al constructor de registro de
venta así que está manejando tanto el catálogo de productos que es el
que contiene la colección que se utiliza para construir este resultado
como el controlador que es el que tiene como rol, como misión precisamente
construir ese resultado por eso se pone así en esta estructura y no otras
estructuras variopintas que se podrían esas otras ya no quieren decir lo
mismo ni implican lo mismo ni implican digamos esa falta de acoplamiento
entre unos elementos y otros y la necesaria cohesión entre las clases y
los objetos que están tratando y manejando una información unos datos de
un mismo tipo y que seguramente dentro de la arquitectura como dicho
anteriormente estarán en módulos que son distintos y que no debe haber
acoplamiento entre unos y otros y eso se debe reflejar aquí ahora qué
pasa cuando estamos manejando distintas colecciones de distintos objetos
pero esas colecciones cada uno de los elementos está correlacionado o
está vinculado de alguna forma esa información en dependencia de la
información que está en elementos de otra colección y que trata por
necesidades de una cohesión alta en el tratamiento como digo podemos tener
una información correspondiente a un elemento y una colección de esos
elementos y nuestra esto sería un multiobjeto o una colección y nuestra
decisión es adaptamos a toda la colección en sí ya os dije el otro día
que si esto se le dota una estructura en el código pues corresponderá un
HashMap un ArrayList un List un Collection las distintas estructuras que
tienen cada lenguaje para organizar una colección de elementos de
información y por tanto no se puede hacer con ellos como tal como
instancia de esta colección no se puede hacer más que los métodos que
tienen que son primitivos para esa estructura si queremos dotar de una
funcionalidad con la que hemos habilitado los elementos de esta colección
necesitaremos un contenedor o un manejador que es lo que estoy llamando
catálogo de manera que digamos en el modelo de dominio el catálogo de
precio de productos es el contenedor manejador que contiene esta colección
y que es una colección se indica mediante esta cardinalidad cuyo elemento
fundamental precisamente es el precio y uno de estos elementos será el que
utilicemos para construir la línea de venta el elemento correspondiente a
el elemento correspondiente del resultado buscado ya os he explicado antes
el cómo funciona aunque el catálogo de precios de productos es un
elemento contenedor y manejador de la colección es un elemento en memoria
volátil nada persistente aunque proviene de un almacén que a través de
la persistencia de un código que permite precisamente refrescar el
contenido de ese elemento incluso ese refresco se podría hacer mediante
mecanismos de código concurrente y refrescarlo constantemente en el caso
de por ejemplo mantenimiento del inventario en el caso de una sesión de
ventas concurrente con otra sesión de ventas en otro lado hay un mecanismo
de código que como digo esta forma de construir el funcionamiento en este
caso no resta generalidad porque podemos construir esta concurrencia y esta
situación mediante esos mecanismos que ya digo vienen al final del libro
bueno esto es que el producto no se pone el tipo en el caso de del modelo
de dominio ni dinero se pone ni string en el caso del modelo de dominio no
se pone ninguno de los tipos pero para describir que efectivamente cada
elemento duplica precisamente por esa necesidad de utilizar alguno de los
elementos del de la colección que necesitamos para construir el resultado
buscado por el actor en el caso de uso lo necesitamos utilizar masivamente
o porque hay riesgo de una perdida de información en el caso de que
desaparezca de esta colección para mantener cual es su identificador y
obtener cual era la información que contenía o simplemente utilizar este
precisamente como manejador de este elemento en el caso de esa utilización
intensiva dentro del funcionamiento del caso de uso entonces conviene
separarlo para su desacoplamiento y para ese utilización intensiva dentro
del funcionamiento del código en una clase separada un objeto separado que
describe uno a uno cada uno de los elementos de esta colección de manera
que el catálogo contiene a todos los elementos de esta colección pero
cada uno de ellos describe está descrito por este productoide este objeto
separado bien este es el que quería digamos el ejemplo al que quería
llegar digamos que resulta que tenemos un sistema donde estamos manejando
los recursos hídricos pues por ejemplo un país, una región un
determinado área geográfica donde tenemos una información de que tenemos
unas cuencas con una determinada información y dentro de esas cuencas pues
tenemos bueno incluso teníamos otra categoría que son las vertientes esto
no me está saliendo a ver donde lo pinto tenemos unas vertientes y digamos
las vertientes contienen una serie de perdón una serie de cuencas y cada
cuenca pues tiene un conjunto de presas incluso cada presa puede contener
un conjunto hay de sensores por ejemplo volumétricos respecto a la
capacidad en estómicos troncúbicos que puede contener de agua almacenada
sensor vale es decir que una vertiente pues puede contener un número
indeterminado de cuencas un número cada cuenca uno indeterminado de presas
pero están asignadas así el caso es que si nosotros como es el caso
queremos añadir, incluir, registrar o dar un alta de una presa nueva
tendríamos que incluirla dentro de esta dentro de esta colección como
componente de una cuenca determinada y a su vez dentro de una determinada
vertiente y a su vez tendríamos que asignarle o posibilidad de asignarle
una serie de sensores nuevos la cuestión es que si vamos a manejar estas
cosas como están enlazadas mantener la independencia el acoplamiento bajo
la cohesión no nos permite que un ítem de esta de esta colección
contenga un listado de los ítems con toda la información de todas las
cosas que contienen y a su vez una de ellas contenga toda la información
porque cualquier búsqueda cualquier información hay que recorrer
absolutamente todo el árbol y eso produce un acoplamiento inaceptable así
que la recomendación es que se creen digamos colecciones separadas y la
vinculación esto es un elemento de vertiente y aquí no puede contener un
listado de las cuencas y con toda la información cada uno de sus elementos
de la colección de cada una de las cuencas sino utilizar un a ver como
pongo esto de manera que cuenca ID está descrito o cuenca ID describe
perdón un identificador de cuenca describe un elemento de cuenca y esta
vertiente tiene un listado de identificadores no de todos los elementos
sino los identificadores cada uno de los cuales está apuntando digamos
hacia la información de esa cuenca de manera que se crean colecciones
totalmente independientes salvo por esta lista que está desacoplada de la
otra colección porque esto es una referencia o sea en lista de cuentas
cuenca tiene el ID de la cuenca tal el ID de la cuenca porque es una
colección el ID de la cuenca cual cada una de ellas apunta a la
información de manera que con cada una de ellas y con el ID
correspondiente acceder directamente a el elemento de la colección con el
que está vinculado o cada uno de los elementos de la colección con la que
está vinculada evidentemente este tiene su catálogo a través del cual
realizaremos las operaciones de su catálogo de cuencas a su vez esta
tendrá un listado de presas y esa colección será los IDs quiero decir
que de la misma manera que he desacoplado esta colección y esta colección
pues lo puedo hacer con la colección de presas con la que está vinculada
para que este catálogo es totalmente independiente de este catálogo de
presas y por otro lado pues lo mismo con los sensores pues este tendrá un
listado de sensores y tendremos un catálogo de sensores etc, etc, etc de
manera que estas vinculaciones entre una colección y entre las colecciones
porque los catálogos el catálogo mantiene su cohesión en cuanto a los
datos que está tratando vale y esta vinculación cruce que hay entre una
información y la otra se arregla se desacopla mediante ese mecanismo que
os he dicho ya hace varias que es el de la indirección es decir interponer
una clase que haga referencia o por referencia a cuál es el elemento con
el que está vinculado vale, pues eso es lo que se representa precisamente
en esto como veo aquí a ver, como veo aquí las cuencas tengo un listado
de presas en esa cuenca y tiene esta relación que contiene un conjunto
entre 0 y n de los ides de la presa a su vez cada una de las presas pues
tiene un listado de sensores que son los ides de los sensores y esta es la
manera en el caso de este caso de uso que resulta que necesitaba dar de
alta bueno, aquí es una complicación en realidad estoy haciendo una
hibridación entre dos casos de uso que deberían ser aislados separados,
no depender uno de otro lo que siempre digo pero en este caso se trataba de
dar de alta una presa, es decir construir una presa nueva y en ese caso
tiene que hacer construir un elemento nuevo de con esta información de
especificación de presa para incorporarlo al listado que de presas que
pertenecen a una determinada cuenca así que para manejar esa información
que digamos parece acoplada que no sabemos en el sistema de persistencia en
el almacenamiento cómo se va a organizar que se puede organizar de muchas
maneras insisto en que no se trata de utilizar claves primarias formas
normales la primera forma normal y todas estas cuestiones que se han estado
viendo a lo mejor en bases de datos incluso en el software no se trata de
utilizar esos mecanismos pero las ideas siempre son buenas de cualquier
asignatura para aplicarlas a pensar en cómo construir el funcionamiento
del código o el el funcionamiento deseado digamos que tenemos en lugar de
una sola lista de precios cada una de las cuales tiene un conjunto de
presas cada uno de los cuales tiene un conjunto de sensores y cada uno de
esos sensores dan un tipo de medidas diferentes son de un tipo distinto lo
que os estoy diciendo es que hagáis colecciones de un solo elemento y ahí
metéis a todos los elementos de ese tipo de información que vayamos a
manejar y manejada siempre por un determinado catálogo vale hay otros
ejemplos como por ejemplo el de no sé ya de hace cuantos años es este
digamos se quería hacer unos cálculos con respecto a los animales el
estado corral y los movimientos que había entre los animales y un corral y
otro y la proliferación de una determinada enfermedad digamos en un
control sanitario bien pues los animales tenían un expediente sanitario
con el expediente sanitario lo que tenía es un un listado de las
enfermedades donde cada una de las enfermedades pues estaba caracterizada
en un elemento de manera que tenemos una colección de enfermedades una
colección de expedientes sanitarios tenemos una colección de animales y
una colección de corrales los corrales contienen animales cada animal
tiene su expediente sanitario y cada expediente sanitario tiene una
colección de enfermedades registradas en ese expediente sanitario se
necesitaba manejar todos estos la información de todos estos elementos
correspondientes a distintas colecciones que se cruzaban entre sí para
realizar unos determinados cálculos y este es otro ejemplo de cómo
desacoplar esas colecciones y su uso mediante una referencia al identificar
el indicador del elemento de otra colección independiente aislada,
desacoplada de otra característica o de otro tipo de información que se
maneja bien, como estamos llegando a las 8 y nos suelen expulsar quisiera
preguntar si hay alguna duda con respecto a lo que hemos dicho, el uso de
los catálogos la concepción del funcionamiento tanto para el modelado
conceptual como ya para empezar a implementar el funcionamiento del
código, pero es muy importante dejar bien claro cuál es el modelado
conceptual en el modelo de dominio no sólo para la entrega de la PEC que
es dentro de nada el día 13 sino para luego construir coherentemente con
ello y necesariamente tiene que tener toda la coherencia con ese modelo
conceptual del modelo de dominio el diseño detallado en la construcción
del código el diagrama de colaboración o de interacción o el de
secuencia, vaya ¿preguntas? por cierto, todas estas etiquetas de
explicaciones también sobran en las respuestas las pongo yo para ilustrar
como os he dicho antes repito lo pongo para poder pintar aquí estoy
poniendo tipos y no se pone ningún tipo lo estoy poniendo para que veáis
digamos esta correlación y este desacoplamiento que estoy logrando con
esta estructura pero ningún tipo aparece en el modelo de dominio ninguno
en principio si un elemento o colección está relacionada con otro objeto
no se duplica aquí no se pone lista de corrales y luego el objeto corral
mediante la relación contenido no, no se pone los elementos que están
contenidos los tipos no se ponen se ponen cardinalidades en todos los
extremos de las relaciones es importante poner eso no se pone las
relaciones no se pone ningún verbo o ningún etiqueta de la relación que
signifique una acción, una responsabilidad de una acción que se va a
resolver con un método un determinado objeto nada son casi todas pues de
contenido el describe pues es de donde procede o que a qué está
representando el captura lo que quiere decir es que es que está manejando
se pone cuando el controlador construye el el resultado buscado por el
actor pues se pone esa relación de captura porque en realidad en el
código luego lo que va a hacer es tirar ese elemento e ir dotándole del
contenido el controlador así que el controlador captura al resultado del
buscado por el actor que inicia el actor, el resultado lo inicia el actor,
el único digamos verbo o relación de acción que se permite la del actor
porque es el que inicia la construcción de ese resultado buscado, alguna
pregunta vale pues muchas gracias los que estéis haciendo la PEC no
olvidaros del plazo de entrega y lo antes posible intentaré corregirlas
para trasladaros las propuestas de mejora y a su vez espero que esté bien
explicado que en el trabajo final hay que volver a hacer la pregunta 1, 2 y
3 y las otras 6 es decir de la 1 a la 9 pero en el trabajo por el hecho de
haber entregado la PEC no hay que dejar de hacer esas tres primeras
preguntas está claro verdad muchas gracias por vuestra asistencia y hasta
la próxima semana