Vale, como dije el otro día, pues iba a empezar esta semana con el
diseño, pero antes, pues preguntar algo, preguntar si hay alguna duda. Una
duda respecto a todo lo que llevamos viendo, o sea, la parte de obtención
de los casos de uso, el análisis general, el modelado de los requisitos
funcionales, antes de empezar, en fin. Voy a repasar varias cosas porque,
en fin, el cómo se hace el modelo de dominio, cada uno de los elementos,
los componentes de los que ya he hablado ampliamente, pero aún hay muchas
cosas que se ven ahora en el diseño y que explican el por qué se colocan
así, se ponen así, se construye el modelo de esa manera en el modelo de
dominio, en el análisis. Es decir, que en el análisis se recogen
determinadas ideas que resulta que provienen precisamente de cómo hacemos
el diseño y cómo queremos hacer ese diseño con esas propiedades, que
siempre repito, de independencia funcional, etc. ¿Alguna pregunta sobre
las cosas que, en fin, determinadas cuestiones que he utilizado en el
diseño? ¿Al costero? ¿Construir, por ejemplo, el modelo de dominio, que
parece que es lo que más inconvenientes produce? Ninguna, vale. Pues voy a
empezar, entonces, con el diseño. Como decía, pues antes de empezar, o a
la par que empiezo el diseño detallado del caso de uso, hola, buenas
tardes. Vamos a ver en qué nos estamos basando. Evidentemente, todo lo que
llevamos dicho o todo lo que llevo presentado son los antecedentes que
producen que el diseño detallado de ese caso de uso se haga de esa manera,
o justifican, sostienen el hacer el caso de uso, el diseño del caso de
uso. Eso es decir, el funcionamiento, diseñar el funcionamiento del
código de esa manera para que funcione así. Con ese objetivo invariable
de que ese funcionamiento tenga esas propiedades que estoy repitiendo.
Entonces, aparte de la visión general, el inicio, la fase de inicio donde
se hace esa visión general y se define cuál es la funcionalidad esencial
del software que vamos a construir. Digamos como antecedentes del diseño
detallado de un determinado caso de uso es previo a todo lo demás. O sea,
incluso hay veces que lo coloco aquí, pero, Es que desde cualquier punto
de vista hay que tener eso en cuenta. Sería la separación de la capa de
presentación, que ya he repetido varias veces, que es la que se refiere al
código cuya responsabilidad es mantener el, la IU, es decir, el formato de
la información que se intercambia de entrada a salida entre el actor
principal, humano, que, eh, que maneja el, el software, lo que, todo lo que
envuelva y lo que se denomina el frontend de, de la aplicación o el
software que, que estamos trabajando, eh, separar también la capa de
servicios técnicos, o sea, eh, el acceso a, a los, a los datos
persistentes al almacén de, de datos, eh, la conexión con actores de
apoyo externos, pues elementos que son, que se definen como externos,
ajenos, bueno, ajenos no, porque interactúan, pero que están fuera del
software, del código que vamos a construir, eh, respecto a el código que
implementa ese funcionamiento, eh, esencial de, el, el software que estamos
construyendo, que sería el código correspondiente al, al, al gobierno de,
de todo ese software y el de la funcionalidad concreta de cada uno de los
casos de uso, eh, la funcionalidad esencial del sistema. Vale. Una vez
hecho esto y teniendo esto presente, que no es una división
arquitectónica, insisto en el código, no es, no es un, un diseño
arquitectónico, eh, de ninguna manera, sino es una primera separación
indispensable para que luego lo que vayamos a construir salga de esta
manera que estoy buscando, eh, con independencia funcional, adaptabilidad y
legibilidad. Eh, eh, dentro de el, el, el inicio ya centrándonos en el
caso, eh, de uso concreto, un, lo primero que haría es, eh, un, lo primero
que haría sería una, establecer una secuencia de, de pasos, de una
ordenación. En los eventos que correspondientes a la interacción entre el
actor principal que es lo que se denomina la escritura del caso de uso. Por
supuesto, esto ya tiene que estar, excluyendo, eh, la interfaz de usuario,
cómo se formatea la, la entrada salida, Ah, Que, Entonces, palabras de
tipo se utiliza un formulario, se toma una lista y se selecciona dentro de
una lista. Todas esas cuestiones correspondientes al formateo de la
información, ahí en la escritura del caso de uso, lo único que nos
interesa es la información. Y el intercambio o la interacción que se
produce entre, o sea, la naturaleza de la información que se va a manejar
y el intercambio, la secuencia del orden temporal en el que se producen
esas interacciones, esos eventos desde el actual. Desde el actor principal
al sistema, tomado como una caja negra, y desde el sistema al actor
principal. Con todo esto construiríamos el modelo de dominio que, insisto,
este modelo de dominio está restringido a esa capa del dominio del
sistema. De la lógica, de la funcionalidad esencial que es la que vamos a
desarrollar e implementar luego en el diseño, en el código
correspondiente al funcionamiento del código es el diseño. La cuestión
es que, como antecedente, este modelo de dominio no solo tiene que tener en
cuenta... Este previo, esa separación en capas que he mencionado
anteriormente, no solo la secuencia dentro de una línea temporal de los
eventos que ocurren en la interacción dentro de la descripción del caso
de uso, estoy hablando de la escritura del caso de uso, sino que tiene que
tener en cuenta una serie de aspectos. Más allá de esa plantilla que se
había puesto, de que tiene que haber un resultado buscado por el actor,
que ese resultado se construye a través de una información que se maneja
internamente dentro de la capa de la lógica del negocio, y que todo eso se
organiza, esa construcción. Se organiza con un objeto que se denomina
controlador del caso de uso, como rol que establece precisamente el orden
de esa secuencia y cuyo ese rol también se ocupa precisamente de ir
construyendo el contenido que tiene ese resultado que busca el actor. Y
todo ello, el controlador del caso de uso y todos los datos que se utilizan
internamente, gestionados, manejados, desde un controlador de nivel
jerárquico superior en esa estructura que habíamos dicho arbórea o
jerarquizada del funcionamiento de cualquiera de las funcionalidades que
estamos desarrollando. ¿De acuerdo? Vale. Así que resulta que en paralelo
a esto, que parece que solo nos vamos a dedicar a lo que tradicionalmente o
dentro de los modelos de desarrollo clásicos se denominaría el análisis,
deberíamos hacer en paralelo, insisto, una construcción de un boceto de
lo que... Es la arquitectura, es decir, la agrupación de los elementos. En
principio, como solo tenemos los objetos conceptuales, pues esa
organización de lo que tenemos por ahora, que son los objetos conceptuales
en módulos, y eso es lo que se define el diseño arquitectónico. Esa
organización de los objetos conceptuales. Los objetos conceptuales en
módulos deberían ser o deben ser, dentro de lo que nos estamos
proponiendo, funcionalmente independientes, adaptables y sencillos,
lógicos. Que tengan una sencillez que les permita una elegibilidad y una
comprensión sencilla de cuál es el funcionamiento y cuál es la
interacción entre un módulo y otro, y por qué, para dar respuesta
precisamente a ese modelo, aunque sea conceptual, que estamos manteniendo
en el modelo de dominio y que a continuación vamos a empezar a construir
en el diseño el funcionamiento del código que realiza precisamente esas
prestaciones que estamos modelando en el modelo de dominio. Así que...
Cuando hagamos el modelo de dominio, también tendríamos que tener
simultáneamente en la cabeza, o bosquejar, o hacer un boceto, de cuál es
el diseño arquitectónico y cómo se organizan de manera independiente, es
decir, con un acoplamiento bajo o débil, y una cohesión alta, cómo se
agrupan esos elementos que estamos colocando en el modelo. Y, por último,
el modelo de dominio en módulos de la arquitectura, de manera que esa
arquitectura ya la vamos construyendo funcionalmente independiente,
etcétera, etcétera. Y tendremos que irnos organizando y situando esos
módulos. Por eso es por lo que sale también el modelo de dominio de esa
manera, con esa estructura, la que aparece en el libro o la que se expone
en... Los ejemplos de las pruebas, digamos, anteriores. ¿Vale? Entonces,
vamos a incidir. Antes de empezar a hacer el diseño detallado del caso de
uso, vamos en cada caso o en cada ejemplo que veamos a ir viendo realmente
cómo se está organizando, cómo se hace, se está construyendo. Digamos,
muy previamente. Precariamente, desde luego. Ese diseño arquitectónico
que está justificando que organicemos los objetos conceptuales en el
modelo de dominio así, y sobre todo, y es a lo que voy en esta sesión de
tutoría, sobre todo que empecemos a construir el diseño detallado de ese
caso de uso desde esa manera y desde... De esa manera. Y desde ese punto,
porque es fundamental, desde donde lo empezamos. No podemos empezar, si
estamos hablando del caso de uso, a construir el modelo de diseño del
funcionamiento del código, pues desde que se inicia la aplicación, porque
es que no es así. Pero la tenemos que imbricar, ese funcionamiento de ese
caso de uso en concreto, desde que comienza, dentro del funcionamiento
general, de la misma manera que hemos tenido que... Entroncar este modelo
de dominio, este modelado de la lógica del funcionamiento deseado dentro
de la lógica del funcionamiento general de toda la aplicación. Es decir,
en coexistencia con otros casos de uso, no temporal la coexistencia, pero
que lo mismo que el sistema funciona para dar respuesta a un caso de uso
deseado, determinado, no se puede utilizar otro código distinto, otro
software, otro sistema distinto para el otro caso de uso. Todos los casos
de uso deben funcionar con los mismos engranajes, los mismos mecanismos.
Hay parte de esos mecanismos que son... Exclusivos para el funcionamiento,
para llegar al resultado final de ese caso de uso y hay otra parte de los
elementos funcionales que los que llamo de gobierno, que realizan su
actuación para cualquiera de los casos de uso, trabajan en colaboración
con el específico de... De un caso de uso y del otro caso de uso, y el
funcionamiento de otro caso de uso no puede modificar el funcionamiento de
un caso de uso concreto. No sé si me explico. Entonces, de la misma manera
que estamos pensando en eso para el modelo de dominio, el diseño
arquitectónico también influye o justifica el cómo estamos haciendo este
modelo, el modelo de dominio y, sobre todo, cómo funciona, cómo definimos
el funcionamiento del caso de uso concreto y el código específico que se
dedica a ese caso de uso en colaboración con el código de gobierno que
gestiona el funcionamiento global y de cada uno de los casos de uso.
¿Alguna pregunta sobre esto? Bien. Centrándonos en el caso de uso de
procesar venta en PDV. Bien. La primera paso, digamoslo así, sería esta
división, como he dicho antes, en tres capas. Aparte de estas tres capas,
hay un software, hay un código, que es el que llamo de gobierno, que está
por aquí dentro, que está actuando sobre esto, que está actuando sobre
esto, que está, digamos, ese código de gobierno tiene acceso,
accesibilidad a todos los elementos indistintamente, sirve de amalgama y
además lo que está haciendo es regulando precisamente todo el
funcionamiento global y específico o facilitando el específico, el
global. El de todo el sistema que estamos construyendo y el específico
destinado solo al funcionamiento de un caso de uso concreto. Bien. Por otro
lado, los elementos específicos de un caso de uso, como puede ser, si
estamos en procesar ventas, pues el específico sería este, el paquete
este que tiene el registro de ventas y el resultado. El registro de la
venta. Esos elementos tendrán necesidad de utilizar determinados elementos
que están por cohesión y por independencia funcional en otro paquete
distinto, en otro grupo diferente, como es el del inventario, donde el
registro posiblemente... Tenga que acceder al catálogo de productos en
venta para obtener su precio, etcétera, etcétera, etcétera. Pero este
está aislado y queremos que tenga el mínimo acoplamiento con este de
ventas y con cualquiera de los otros. De manera que hay que buscarnos un
mecanismo para que dentro de estos módulos... La arquitectura de la capa
de dominio haya, entre ellos, el mínimo acoplamiento o el acoplamiento
más débil posible y dentro de lo que tratan y manejan en cada uno de
estos módulos haya la máxima cohesión, la cohesión más alta. Quiere
decir que si, por ejemplo, en inventario o en otras partes del libro... Lo
llama productos, el paquete productos. Pues tendremos todos los elementos,
objetos, en este caso que estamos en el modelo de dominio, objetos
conceptuales que manejan los productos en venta para saber su precio. Pero
es que en otro caso de uso, a lo mejor necesitan, por ejemplo, para compras
de... De productos para el inventario. Pues en un caso, como he dicho en
otras ocasiones, tendremos la colección de precios de los productos y el
correspondiente catálogo. De manera que este catálogo está manejando
esta colección. Esta colección. Los elementos se manejan cada uno de
ellos. O... La forma... La forma en que se manipulan los elementos dentro
de esa colección. Pero para otro caso de uso podemos necesitar dentro de
esta misma colección, quiero decir, información correspondiente a los
productos, para que tenga una cohesión lo máxima posible, pues
necesitaremos otra colección distinta. Con otra información también de
los productos, pero eso corresponde a un catálogo, pues por ejemplo, de
compras del inventario. Vale, pues tendremos otra colección y otro
catálogo. Pero por estar todos manejando la información correspondiente a
los productos, estarán dentro de ese paquete. Y queremos que cualquiera de
ellos, cualquiera de los elementos o el paquete en sí... O el módulo o
componente, como queramos llamar, tenga el mínimo acoplamiento con los
demás. ¿Queda esto claro? Primero, la separación en las tres capas y la
que amalgama todo, que sería la de gobierno. A partir de entonces nos
centramos sólo en esta, en la capa de la lógica del... del... el dominio
de la lógica del negocio. Y aquí es donde también tenemos que definir
esta arquitectura. Como veis, ventas, el paquete ventas y todo lo que se
haga para procesar venta, pues estará relacionado con la parte de usuario
de procesar venta, pues para crear las ventanas... los elementos, las
listas o lo que tenga que ver. Pero está desacoplado, está desacoplado
uno con otro. Tendrá relación, pero se hará igual que he explicado con
el acceso al almacenamiento de los datos. Mediante una interfaz abstracta y
un adaptador especializado para ese elemento de almacenamiento y de
gestión de los datos. del almacenamiento específico que vayamos a
utilizar eso es fundamental y por eso hay que pensar constantemente que al
separar esto así es porque queremos que haya desacoplamiento entre una
cosa y la otra bien, una vez que tenemos y pensamos de esa manera lo que
estamos haciendo es una organización para aumentar la cohesión y ya
veremos cuando hagamos la implementación del funcionamiento también que
haya un acoplamiento lo más bajo posible en principio organizamos estos
módulos pues el módulo de venta donde colocamos esto el módulo de
inventario donde ya he dicho que a pesar de que aquí en esta
representación solo sale la interfaz que se está conectando con la base
de datos a través de la capa de servicios técnicos, es decir a través de
la fachada con la base de datos pues tendremos aquí como he dicho los
catálogos de las colecciones que vayamos a manejar en cada caso de uso
dependiendo donde se esté manejando la información en cada caso de uso
será información de otro tipo independientemente de que aquí pues esté
toda la cosa toda la información correspondiente a los productos estará
guardada aquí, sea para proveedores y comprar nuevos productos o sea para
las ventas o sea para devoluciones o sea para lo que sea todo está
almacenado aquí pero al recogerlo nosotros lo organizamos según la
conveniencia para el caso de uso que nosotros estamos manejando bien una
vez que definimos esto cuando vayamos a perdón cuando vayamos a elaborando
ese funcionamiento pero conviene ir ya pensando cómo es o qué es así?
pues podremos establecer más detalle en cuanto a cómo hemos separado
estos elementos en módulos o paquetes o componentes de la arquitectura
veríamos una cosa similar un mapa similar al anterior sólo que aquí pues
está marcado ya el donde nos centramos que es en el modelo de dominio y
básicamente aquí ya se están viendo o se están representando cuáles
son las relaciones en principio los acoplamientos que va a haber pues entre
el paquete de ventas y el el catálogo de productos el inventario bueno
pues hay otro paquete donde tienes las estrategias respecto a fijar los
precios que se van a poner que afectan precisamente al resultado a los
ítems vendidos a la venta en cada caso el motor de reglas de PDV que a su
vez este se está interactuando con un, con un gestor de reglas un sistema
experto que es lo que es Yes basado en reglas para definir cómo está
trabajando cómo funciona el negocio todo el negocio pues tanto ventas
devoluciones etcétera, etcétera, etcétera bien, pues para conectarse con
esa eh... elemento externo específico como puede ser ese motor de reglas
del sistema experto pues el propio módulo ventas tendrá un acoplamiento y
una relación precisamente con esto se explica más adelante en los
capítulos finales pero simplemente para explicaros que ya se empieza a ver
y por eso hay que tener buen cuidado de cómo hacemos esta agrupación en
el diseño arquitectónico para que ir previendo que los acoplamientos
tienen que ser y las relaciones tienen que ser lo más débiles posibles y
no que esté todo absolutamente acoplado con todo lo demás o dentro de un
caso de uso que resulta que se da a distintos sitios que no tiene vamos que
se puede evitar y generar y evitar generar un acoplamiento que puede
resultar inaceptable tenéis que tener bien claro qué significa eso del
acoplamiento y el acoplamiento lo que significa es la dependencia entre el
funcionamiento pero no porque se use sino porque si se modifica el
funcionamiento de un determinado elemento si se modifica a quién está
afectando o a qué otro o a qué funcionamiento de cualquier otro elemento
situado en otro módulo o simplemente otro objeto le puede afectar o
obligar a modificar el contenido de sus métodos precisamente porque hemos
cambiado un determinado método en este elemento así que si el modificar
el funcionamiento o cómo se maneja la información de un determinado
objeto en cualquier clase podemos llamarlo también un módulo en cualquier
granularidad de lo que estemos percibiendo o observando si el cambio si la
modificación en un método de uno de esos elementos afecta a otro elemento
al funcionamiento de otro elemento y nos obliga a modificar un método de
otro elemento eso es lo que tenemos eso se llama un acoplamiento fuerte y
eso es lo que tenemos que evitar aquí está el catálogo que maneja una
determinada colección si tenemos que meter si el funcionamiento nos lleva
a meter métodos aquí que hagan determinadas cosas y esas cosas son solo y
únicamente utilizadas en otro módulo eso está produciendo un
acoplamiento y eso es fuerte alto y eso es inaceptable rompe la cohesión y
rompe todo si yo tengo este catálogo que está manejando los elementos de
esta colección aquí meteré los métodos para hacer cosas genéricas con
esta colección este catálogo que está manejando los elementos de esta
colección el catálogo que se ocupa de manejar esa colección es la
información con esa información que tiene los elementos de la colección
quiero decir pero si dentro del elemento ventas el módulo el paquete de
ventas por ejemplo el controlador de ese caso de uso lo tendré que
implementar dentro de este módulo en este caso como de lo que estoy
hablando será el controlador de ese caso de uso el controlador el que
recibirá un elemento y ahí un elemento siguiendo el libro un elemento de
especificación spec del producto y con ese elemento hará lo que sea
tendrá métodos para hacer lo que sea con ese elemento no sé si me
explico que en el caso de uso no se inyectan métodos ni funcionalidad en
objetos cuyo objetivo y por cuya cohesión se refieren al manejo de sus
propios elementos su propia información cosas que son se hacen
exclusivamente en ventas en el paquete ventas no se van a meter en el
catálogo de elementos de esta colección de la colección spec del
producto por mucho que el controlador del caso de uso en este caso registro
de ventas o registro utilice algunos de los elementos ni siquiera porque
utilice una copia así que no tiene sentido meter aquí en el catálogo que
sólo maneja elementos de la colección o la colección spec del producto
no tiene sentido meterle métodos cuya responsabilidad o funcionalidad se
refieren única y exclusivamente a lo que se hace en el caso de uso de
ventas no sé si esto ha quedado bien claro es un error muy común empezar
a meter ahí métodos que no se corresponden y no sé tampoco si hay alguna
pregunta al respecto quiero decir que eso hay que asimilarlo pero si ocurre
de momento alguna pregunta o alguna duda bien vale seguimos con el proceso
lo que hemos visto antes de esta parte de aquí y en lo que se refiere al
paquete al módulo de ventas y lo que se hace dentro de él tendríamos
aquí un detalle que esto se ve fatal bien aquí tendríamos ahora lo
amplio aquí tendríamos ventas dentro de ventas pues tendríamos el
resultado buscado con sus atributos etcétera que está formado por una
colección de elementos líneas de venta que a su vez lo construye está
capturado por el controlador de ventas que en el caso del libro lo llama el
propio registro registro vale para ser un poquito más específico yo le he
llamado aquí registro ventas vale pero es el mismo registro que viene en
el libro para construir esto el registro ventas está utilizando me parece
que lo he pintado mal bueno está utilizando el catálogo de productos de
venta vale ese catálogo de productos de venta pues como hemos visto en el
modelo de dominio pues tiene una colección de aspecto de producto que es
lo que maneja y cada uno por lo que hemos hablado del identificador único
para cada elemento por el motivado o productoide motivado primero por ese
desacoplamiento y ese desacoplamiento que queremos conseguir está motivado
porque aquí en registro ventas se va a hacer un uso fundamental intensivo
de spec del producto entonces en lugar de manejar spec del producto con
todos sus atributos etc, etc en determinadas operaciones lo que vamos a
manejar es el manejador el articuloide en cualquier forma esto va a estar
manejado única y exclusivamente por el catálogo así que el catálogo va
a estar manejado por registro ventas más que manejado es que va a ser un
componente suyo es un atributo suyo se crea precisamente con el constructor
se le pasa como argumento en el constructor bien entonces no es la venta la
que tiene esta bueno sí es verdad perdón esta flecha de acoplamiento y de
relación esta flecha de acoplamiento y de relación bien puesta porque
resulta que la venta al al calcular cuál es el coste tiene que calcular
también sus impuestos debido a que tiene que calcular sus impuestos es por
lo que accede a este paquete que se llama servicios de acceso y a través
de este este objeto factoría de servicios que es una un objeto un
singleton y es una factoría abstracta lo que obtiene es un manejador una
interfaz de adaptador de impuestos que genera un adaptador especializado en
el cálculo de impuestos que a su vez a través de la capa de servicios
técnicos accede a un elemento externo que se denomina calculador de
impuestos entonces por eso es por lo que tiene esta vinculación a este
elemento que le dota de este adaptador de impuestos especializado para que
pueda acceder al exterior no es a través del controlador de nivel superior
el que estuviera por ejemplo el main y que tuviera aquí un código que le
permitiera comunicarse a su vez con él no o tienda o como se quiera llamar
no una vez que se invoca al controlador del caso de uso es el único que
existe no puede haber comunicación si tenemos bueno ahora lo vamos a ver
en otra si tenemos tienda como controlador digamos jerárquica de
jerarquía superior antecedente y hace crea el controlador del caso de uso
que hemos dicho que se llama registro o registro ventas luego no se puede
comunicar ni transferir a tienda hasta que no haya terminado este de hecho
el actor sólo se comunica con el controlador y con uno solo además con el
controlador que esté activo en cada momento aquí será tienda y cuando le
dice ventas pues entonces hace lo que tenga que hacer el jerárquicamente
anterior y una vez que invoca el controlador del caso de uso delega en él
y a partir de ahí ese mismo actor se comunica con este no con tienda y se
hacen puentes etcétera etcétera de manera que registro no se puede
conectar con tienda ni enviar mensajes a tienda ni nada parecido bien una
vez dicho esto lo que estaba diciendo es que de la misma manera el main lo
primero es que crea una instancia del catálogo de productos el catálogo
de productos lo que hace es pedirle a esta factoría de servicios un enlace
un adaptador para conectarse aquí están las puntos que no aparecen aquí
dentro del paquete de persistencia de la capa de servicios técnicos
tendríamos aquí pues la fachada de base de datos y es esta la que se
conecta con la fachada de esta base de datos concreta bien para que es esto
porque necesita el catálogo que maneja esta colección los elementos de
esta colección porque necesita acceder a la factoría de servicios todos
estos este es un objeto estrictamente software solo código es un artificio
de código necesario para que este se comporte que es un objeto conceptual
también para que este objeto conceptual cuando se pase a código se
comporte de esta manera que nosotros estamos diciendo como he dicho
anteriormente resulta que todo esto está en memoria evanescente volátil y
no se nos ocurre cargar toda la base de datos toda la información esta
información de la descripción el nombre, el precio y el ID del artículo
no se nos ocurre cargar todos los productos que hay en la memoria para que
lo maneje este según lo necesitemos pues iremos utilizando y accediendo
precisamente a la base de datos para ir recuperando todo lo que hacemos y
eso se hará en los métodos que vayamos poniendo dentro de la del
catálogo para manejar los elementos de esta colección pues en el código
que metamos en determinados métodos lo que haremos es busca en local o haz
lo que sea en local el elemento que queremos manejar entonces utiliza este
adaptador y búscalo en en el almacenamiento persistente lo recoges y
entonces ya haces lo que tengas que hacer eso no es conceptual eso es un
artificio de código de esta manera que nosotros habíamos puesto en el
modelo de dominio bien eso es por lo que tienen estos enlaces con esto y
entonces efectivamente hay un acoplamiento vamos un acoplamiento una
relación con el catálogo de productos y con algún elemento de
especificación de producto una vez que se lo pida ya con esa
especificación del producto ese elemento de la clase spec del producto si
tiene que hacer cualquier cosa ya serán métodos que están dentro del
registro porque son específicos de el caso de uso procesar ventas no tiene
que ver con lo que se puede hacer comúnmente con la los elementos de la
colección especificación de producto y que esos métodos pues si pueden
estar aquí dentro del catálogo para dotar de una cohesión alta a los
elementos que hay dentro de este módulo pero como veis dentro de el caso
de uso se están utilizando objetos estrictamente de código o objetos que
además son objetos conceptuales aunque luego que luego se conviertan en
código puro se están utilizando objetos de otras clases de manera que un
caso de uso en general no define una clase de la arquitectura o los objetos
que intervienen en el funcionamiento de un caso de uso específico no
están dentro de un módulo identitario de ese caso de uso sino que habrá
alguno que sea específico del caso de uso y que si lo podemos colocar como
aquí en procesar ventas en el paquete en el módulo de la arquitectura
ventas que será el resultado desde luego perdón el resultado desde luego
y el controlador del caso de uso aunque el controlador del caso de uso por
ser el registro de ventas en otros diagramas también se pone fuera en el
nivel de dominio digamos como partícipe de este elemento que hemos llamado
de gobierno coordinación global de toda la aplicación insisto si hay
cualquier duda o hay algo que no me explico bien o que no quede bien claro
lo que es evidente y parece de perogruyo pues vale entiendo que no haya
dudas pero si las hubiera es es mejor preguntarlas ahora luego cuando se
empieza a reflexionar pues suelen surgir bastantes dudas o incluso a la
hora de hacer el cualquiera de los ejercicios ejemplos pasados o la prueba
actual vale debido a todo lo anterior pues tenemos digamos esta
organización que he insistido tanto en poner tenemos aquí el resultado
buscado por el actor el registro ventas que es el controlador del caso de
uso el controlador de nivel jerárquico anterior que lo hemos llamado
tienda que es el que maneja porque está en otro módulo el catálogo de
productos que contiene la colección de características del producto que
se está vendiendo entre ellas el más importante sería el precio y esto
se correspondería con ese módulo que hemos determinado denominado ventas
no perdón esto sería productos y como veis estos elementos que forman
parte de el paquete o el módulo o el componente de la arquitectura de
productos junto con otros catálogos y otras colecciones etcétera
etcétera que se utilizarán seguramente para otros casos de uso lo que se
está utilizando aquí no vamos sí es una instancia de este paquete pero
que se trae como copia a este caso de uso en local así que lo que se haga
aquí que no se debe hacer nada en principio no se hace nada porque el caso
de uso no quiere que se modifique nada de esto lo que se haga aquí se
queda aquí como mucho esto va a quedar como un componente porque el
controlador es el que construye esto y por lo tanto lo crea y lo va
construyendo elaborando con todo el funcionamiento que estamos describiendo
así eso quedará como un componente de registro ventas que al final
volverá a la tienda y ya y a partir de ahí la tienda pues hará lo que
tenga que hacer por ejemplo mandarlo a contabilidad y facturación mandarlo
a inventario para que ajuste los las existencias el número de existencias
que hay respecto a los productos que ya están vendidos etcétera etcétera
pero eso ya queda fuera del caso de uso y hemos colocado estos elementos
que aquí en este modelo en este diagrama son conceptuales los hemos
colocado así debido a todo esto que hemos estado analizando viendo como
agrupar etcétera etcétera aquí si no es por esta justificación es
posible que pudiéramos encontrar otra forma de organizar esto pero esta
forma de organizarlo con estos antecedentes que os acabo de decir sí que
tienen garantía porque ya lo estamos pensando así y lo estamos
construyendo de esta manera que tienen una cohesión alta y abajo y estamos
construyendo con una independencia funcional notable con una flexibilidad
por tanto aceptable adecuada y con una sencillez suficiente como para que
esto pueda entenderse con facilidad qué pasa con el caso de uso para
construir precisamente el diseño detallado de ese caso de uso pues como
digo es importante primero imaginarnos o concebir o analizar y ya colocando
los elementos en el modelo de dominio lo que se hace es identificar y cómo
se estructura como la organizamos en estructuras para poderla utilizar es
decir ahí estamos dando un matiz del funcionamiento que estamos
representando en el modelo de dominio pues de todas las estructuras que
podamos dar a esa información tenemos que elegir una tal que si la
situamos en el diseño arquitectónico ya nos esté dando garantías de que
hay esa independencia funcional es decir un acoplamiento débil y una
cohesión alta pues dentro del a ver dentro de el paquete de cargar un
determinado buque el resultado era este se carga el buque determinado este
de aquí el buque tiene distintos tanques para rellenar o cargar con
distintos productos contiene una colección de elementos de una cantidad
determinada de un producto hidrocarburo que se carga en cada uno de esos
tanques y además se hace una determinada maniobra con unos parámetros
físicos de cómo ha ido la carga con qué presión se ha hecho etcétera
que son una información sí una descripción inherente a cada uno de estos
cargas de tanque que se han hecho dentro de la carga del buque eso sería
el resultado podríamos incluir también el gestor de la carga del buque
como controlador del caso de uso en este caso no lo he metido dentro de
este paquete porque es que había varias opciones de carga y es posible que
dentro de estas opciones de operaciones carga y descarga pues este mismo
controlador pudiera contener el código para una o para otra puesto que se
utilizaban exactamente los mismos objetos etcétera siendo el
funcionamiento de uno totalmente independiente del otro aunque el
controlador lo podamos denominar para tener los métodos para ambos para
carga y para descarga pero evidentemente la otra operación que es traslado
o la otra operación que sería mantenimiento de un buque esa sí que no
tiene los mismos métodos ni utiliza los mismos objetos ni conceptuales ni
de código puro así que no lo podríamos meter dentro de ese paquete al
código de maniobra perdón de gobierno de toda la aplicación GESFLOTA
bien, la cuestión que esto está así muy pequeño y lo voy a detallar es
que la operación de carga de un determinado buque utilizaba tres tipos de
información la información correspondiente al buque en sí que es creo
que esto bueno aquí se ve fatal ya lo voy a poner más destacado la
información del buque en sí concreta que vamos a cargar sí, sí lo he
digamos fraccionado en trozos que en las siguientes pantallas pues se vea
con más detalle pero esto es para que veáis digamos una organización
global de todo ello de todo ello para este caso de uso porque aquí habrá
más módulos y más paquetes a lo que voy y quiero reseñar para darnos
una imagen general es que utiliza tres tipos de información que deberían
pertenecer a bloques de la arquitectura a módulos o componentes de la
arquitectura que deberían estar separados que son la información
correspondiente a los buques que sería esta la información
correspondiente a los puertos que sería esta y la información
correspondiente a los productos con los que se carga precisamente la
información que es del buque con lo cual tendríamos por cohesión tres
paquetes uno para buques y la información que se maneja dentro de buques
con su catálogo con su adaptador con su interfaz de acceso al
almacenamiento almacenamiento externo o que definimos como externo para lo
cual utiliza esa factoría abstracta de obtención una factoría de
servicios con la cual se obtiene esta singleton factoría abstracta de
servicios aunque esté dentro de este paquete está definida para que
cualquier elemento, aunque sea de otro paquete pueda acceder a ella y
generar producir un determinado objeto ¿de acuerdo? eso es un mecanismo
estrictamente de código aparece por supuesto en el modelo de dominio y del
cual de momento nos vamos a olvidar pero lo menciono precisamente para
justificar eso de que todos están en memoria pero se puede acceder a toda
la información correspondiente ¿por qué? porque luego vamos a
implementar mecanismos de código estrictamente código, no es conceptual
por los cuales se va a comportar así y vamos a implementar ese
comportamiento por eso os lo quiero mencionar para que veáis que aparece
aquí y es parte del código pero lo que estaba diciendo es que tenemos
tres módulos con su catálogo que maneja la colección correspondiente
aparte de la interfaz que le da acceso al almacenamiento persistente de los
correspondientes la correspondiente información que se está manejando
este módulo utiliza de este módulo del módulo de buques vamos a
detallarlo pues si que se detalla mucho se sigue viendo fatal no sé si
esta imagen ya la he puesto anteriormente en otra presentación en
cualquier caso la incluyo en los pdf que se aportan como documentación
adicional de la de la grabación de la sesión de tutorial grabada y os lo
podéis descargar y ampliarlo todo lo que queráis para que se vea
medialmente bien aquí desde luego se ve un poquito más grande tampoco
quiero alardear el paquete de buques como la descripción la
especificación del buque pues tiene un una colección de tanques donde se
cargan los productos el catálogo correspondiente y el adaptador este es
estrictamente código que es de tipo especialización de esta interfaz que
precisamente provee esta factoría abstracta de servicios el controlador
que hemos dicho el resultado de la carga del buque y esto es lo mismo que
el de buques pero para los productos de hidrocarburos que se cargan bien
con esta justificación y con todas esas otras cosas que hemos dicho sobre
porque construimos de esta manera por eso llegamos a esta organización del
modelo de dominio que se seguirá viendo mal porque esto yo veo mal pero
encima me tengo que quitar las gafas para poder ver algo tenemos el
resultado buscado por el actor que es la carga del buque correspondientes
atributos la de cada tanque donde el actor aporta la cantidad de lo que sea
de refinado o de crudo o de lo que sea que se carga en ese tanque y a su
vez los resultados de la maniobra como el compendio de parámetros físicos
trasladando el actor para esa carga concreta de producto en ese tanque para
construir los elementos correspondientes a este resultado la carga del
buque se utiliza la información del buque catálogo de buques con su la
identificación es decir la descripción del objeto que se va a manejar de
entre una colección en lugar de manejar toda la descripción pues para la
utilización estaremos utilizando un indicador asociado a cada uno de los
elementos de la colección y a su vez cada uno de los elementos de la
colección que está aquí una colección de tanques en los que se describe
la cantidad real de carburante o de producto hidrocarburo que hay en ese
tanque en ese momento la capacidad total el identificador del producto y el
nombre del producto a ver otra vez aquí HashMap y aquí ArrayList aquí no
hay más vale os digo en el modelo de dominio no se pone ningún tipo de
los atributos por supuesto métodos mucho menos y estos estereotipos que
estoy poniendo aquí que yo le he querido dar una determinada estructura a
los elementos de esta colección pero tampoco se pone no se ponen los
estereotipos bueno de hecho dentro de este modelo de dominio ahora mismo no
recuerdo porque este es un HashMap y este es un ArrayList pero en general
son objetos conceptuales así que no tiene ningún sentido que esto
denominarlo HashMap ni nada de eso como he dicho en otras ocasiones todas
estas etiquetas donde intento aportar o ilustrar algún concepto alguna
ayuda al respecto tampoco tienen mucho sentido ni cabida esto lo pongo como
ilustración para quien el estudiante pero en un modelo de dominio en la
evaluación en concreto tampoco tiene sentido llenarlo o poner un montón
de notas aquí explicando lo que ya de por si tiene que estar indicando lo
que es el diagrama y creo que no hay nada más que llamar la atención
insisto que para construir la cuestión, el hecho es que para construir
este el contenido estos contenidos de aquí voy a necesitar tres elementos
colecciones de información la de la información correspondiente a los
buques la información correspondiente a los puertos y la información
correspondiente a los productos vamos que debido a esto es por lo que hay
tres colecciones porque de ahí se nutre como voy a construir el contenido
del resultado de la misma manera que procesar venta solo se necesita el
precio de cada producto y sólo se utiliza una colección y un catálogo
igual que en la PEC de este año GESAMA pues se utiliza la información
correspondiente a las fincas la información correspondiente a las
máquinas y como lo que se quiere es crear una reserva nueva pues la
información correspondiente a las reservas con las que están
comprometidas ya las distintas máquinas pues esos son elementos que se
están manejando internamente dentro de la de la aplicación y del caso y
para este caso de uso son necesarias pues estos son los elementos que he
denominado modelo de datos y que todo ello tiene que tener en cuenta que la
información que se maneja y esa independencia funcional acoplamiento bajo
entre ellos y entre cada uno de estos elementos es por lo que se organizan
así lo que por ejemplo si es que esto se ve se sigue viendo fatal por
ejemplo un buque he dicho que tiene varios tanques en el tanque pues lo que
tendré será el nombre del producto que se almacena dentro de ese tanque
el nivel de carga que tiene registrado en en ese tanque la capacidad total
que cabe dentro de ese tanque no todas las características del producto
que se está almacenando sino que se hace relación para no hacer una
vinculación un acoplamiento entre un elemento de estos y un elemento de
especificación y descripción del producto se hace a través de su
manejador de manera que esto especificación del buque tendrá una
colección de tanques cada uno de los cuales tiene un identificador del
producto que contiene en ese tanque no de las características físicas o
la descripción del producto que se almacena en ese tanque esto es como he
dicho bastantes veces una manera de desacoplar igual que en la
especificación del buque estará ubicado un puerto amarrado y no se ponen
todas las características del puerto con todos los depósitos que contiene
ese puerto con las características del producto etc, etc que tiene cada
uno de esos puertos sino que se referencia mediante el manejador de ese
puerto el puerto ID y ese es el que se indica dentro de su ubicación ID o
si está en tránsito pues un indicador que le diga que está deslocalizado
en tránsito o como se quiera llamar de acuerdo es la manera de romper esos
acoplamientos entre uno y otro entre elementos que pertenecen a colecciones
que son distintas y que deberían estar en módulos separados para mantener
la cohesión de la información que manejan y desacoplados entre sí y con
los elementos específicos como es gestión de carga del buque el
controlador específicos del caso Dios ¿alguna pregunta más? ¿alguna
pregunta? no hay preguntas por ahora vale he dicho que en parte la
organización de los objetos conceptuales que se coloca en el modelo de
dominio modelado conceptual del funcionamiento deseado de la lógica del
funcionamiento deseado para el caso de uso está justificada y se soporta
por como organizamos los objetos dentro de una arquitectura futura una
organización arquitectónica futura que vamos a ir construyendo que ya
estamos construyendo poco a poco con esa arquitectura se fundamenta con
todo lo que he dicho en las sesiones anteriores y con esto de la
arquitectura con esta arquitectura y todos estos fundamentos que hemos
estado diciendo antes de comenzar el diseño detallado del caso de uso es
decir, a construir ya cómo funciona el código para dar soporte a ese
modelo de dominio y la escritura del caso de uso que hemos construido las
idas y venidas del proceso unificado de la forma de trabajar y de
desarrollar el proceso unificado se refieren a esto que nosotros estamos
construyendo el modelo de dominio y no hacemos solo el modelo de dominio o
lo planteamos inicialmente pero empezamos a construir el diseño
arquitectónico y una vez planteado el diseño arquitectónico empezamos a
construir este funcionamiento del que voy a hablar ahora y después
empezamos a construir el funcionamiento del caso de uso el comienzo del
funcionamiento del caso de uso en cada uno de estos pasos que os acabo de
decir podemos darnos cuenta de que tenemos que estructurar de otra manera
los objetos conceptuales que estamos poniendo en el modelo de dominio
resulta que no cumple con estas propiedades que estoy buscando y entonces
eso es las iteraciones idas y venidas hacia el análisis y vuelta al
diseño arquitectónico diseño detallado etcétera, etcétera esa
secuencia de modificaciones y refinamientos no tienen ningún sentido en
las respuestas del de la evaluación porque allí se recoge el diagrama en
cada caso del artefacto que se esté pidiendo el resultado el diagrama ya
refinado totalmente en algunos ejemplos de pruebas anteriores voy buscando
en el documento los pasos en el desarrollo y voy planteando distintos
diagramas pero eso es con una intención totalmente didáctica ilustrativa
de cómo se va elaborando cada uno de esos diagramas no tiene ningún
sentido incluirlos de lo que iba a hablar ahora es que el siguiente paso
una vez que ya tenemos más o menos la arquitectura hay que entender bien
dónde empieza de todo el funcionamiento este funcionamiento que ya os he
dicho anteriormente que es jerárquico, etcétera etcétera, dónde empieza
el funcionamiento del caso de uso y para entender bien dónde empieza el
funcionamiento del caso de uso la cuestión es concebir cuál es el
funcionamiento de los antecedentes o el previo al caso de uso para
determinar en qué estado se quedan los objetos que vamos a utilizar y
manejar el caso de uso en el caso de procesar venta como he dicho muchas
veces se iniciaría en el momento que entra a controlar el controlador
único del caso de uso pero para ello necesita una información que no
puede recoger él puesto que no está creado previamente la tiene que
recoger otro elemento pues será como también he dicho el controlador de
nivel jerárquico anterior o antecedente o el funcionamiento del
controlador del caso de uso esa información que requiere sería la de la
colección de los precios de los productos lo que hemos llamado
especificación del producto como esa especificación del producto ya os he
dicho que no se va a almacenar está toda en memoria pero no se va a
almacenar todo el contenido de todos los elementos sino sólo una parte de
los elementos o dependiendo de lo que se tenga que hacer pues necesita un
acceso al almacén persistente es el catálogo de precios de productos
aunque esté dentro de un módulo que debe estar desacoplado con todo lo
demás ese clase catálogo de productos en su creación lo que tiene que
hacer o para conseguir este elemento tiene que invocar como os he dicho
esta factoría de servicios es de carácter global y visible por todo desde
cualquier punto del código de la aplicación pues accede a esta factoría
para que le dé un adaptador específico de esta clase esta actor externo
del almacenamiento persistente bien pues lo que crea es un adaptador
abstracto que lo especializa en servicio de productos que es un adaptador
para la base de datos de producto una vez que lo tiene ya incluido como un
componente el catálogo tiene el adaptador servicio de productos entonces
el controlador de la clase anterior del nivel jerárquico anterior
antecedente lo que hace es crear el controlador delegarle el servicio y en
la creación lo que le hace es pasarle como parámetro como argumento el
catálogo de productos y eso es una copia de ese elemento de manera que lo
que haga en esa copia se va a quedar aquí dentro del registro de ventas y
ahí se va a quedar bien entonces estos son los antecedentes y a partir de
aquí es cuando empieza el caso de uso el funcionamiento del código
correspondiente al caso de uso antes se ha creado todo esto porque el
controlador del nivel anterior tiene la inteligencia suficiente para saber
que con el caso de uso de procesar una venta se necesita el controlador y
ese controlador va a necesitar para construir el resultado esta colección
o el catálogo que maneja esta colección en concreto entonces por eso
estamos una vez que empieza el caso de uso procesar venta es por lo que
tenemos este elemento y tenemos este catálogo y disponible ya la
información que va a ser necesaria en la construcción del resultado
buscado que ocurre en el caso de uso procesar carga buque pues que en el
caso de uso de procesar carga buque vamos a necesitar la información
correspondiente a los buques la colección de informaciones
correspondientes a cada buque y el correspondiente catálogo la de los
puertos la información de los productos que se van a cargar en su no
sabemos el buque todavía no sabemos el puerto en el que pueda estar
amarrado sabemos la cantidad de puertos que hay pero no en cuál está
amarrado el buque que nosotros hayamos determinado porque no ha empezado el
caso de uso y por tanto no se ha determinado cuál es el buque que queremos
cargar ni por supuesto los productos hidrocarburos que se van a meter en
los distintos tanques entonces cuando el actor una vez que ha iniciado la
sesión y está dentro del sistema y está todo en el nivel jerárquico
anterior al caso de uso invoca la orden de carga buques entonces ese
controlador lo que tiene que hacer es primero buscar o crear la colección
de información correspondiente a los buques pero no sabemos en qué puerto
está pero sabemos que si se va a cargar un buque necesariamente tiene que
estar amarrado en algún puerto así que de todos los buques posibles que
se van a utilizar dentro de la información de esta colección que se va a
necesitar no se van a utilizar todos sino que necesariamente va a ser un
subconjunto correspondiente a los buques que estén amarrados en algún
puerto los que estén en tránsito o en mantenimiento no van a poder ser
así que a la hora de cargar este buque por supuesto accede a la factoría
de servicios para obtener el adaptador especializado para esto vendrá por
aquí está la fachada persistente de la fachada de base de datos y eso es
la que se conecta entiende con la base de datos el adaptador de base de
datos buque y a la hora de hacer buques para cargar hace una consulta al
servicio adaptador que accede a al almacenamiento externo para que busque
cuáles son los buques que son susceptibles de ser cargados es decir
aquellos que no estén amarrados es decir efectivamente el este adaptador o
este catálogo entre los métodos que puede tener será el de las consultas
de la información de los elementos que contienen contenidos en su
colección así que sería una consulta cuyas condiciones sería que el
buque esté activo que la ubicación no sea en tránsito y y que sus
tanques estén vacíos de contenido porque si está lleno tampoco se va a
poder cargar y de para que devuelva precisamente la colección de
especificación del buque en esta consulta vale esto se hace de otra manera
vamos a ver lo primero que se hace es buscar el adaptador luego se crea un
multiobjeto vacío cuyos elementos serían spec del buque se hace la
consulta y se van trayendo cada uno de los elementos se crea un elemento y
ese elemento después se añade esta colección y así se va creando los
elementos de colección este mecanismo es exactamente igual al mecanismo de
ir añadiendo elementos en una colección en el producto o en el resultado
buscado por el actor es decir hay determinados mecanismos pues que ya
deberíais familiarizar os con ellos como la de dar crear elementos dentro
de una colección pues ya os acabo de decir primero se crea la colección
vacía luego se hace lo que sea y se crea uno de los elementos de este tipo
elemento de la colección y después se añade ese elemento a la colección
es un mecanismo habitual que se repite constantemente sea la estructura que
tenga la colección como la que estamos manejando manejemos directamente la
colección o sea el catálogo el que esté manejando la colección de
acuerdo bien pues lo que decía es que en este caso puesto que sabemos al
crear la colección de información de los buques la los buques van a tener
que ser que estén amarrados en algún puerto pues ya creamos la colección
que vamos a utilizar de esta manera y establecemos esa condición en la
consulta o en la búsqueda al elemento externo para crear esa colección de
elementos de información de buque que maneja el catálogo de buques en
cuanto al catálogo de puertos pues como no sabemos qué buque es tampoco
sabemos en qué puerto va a estar amarrado así que pues crearemos el
catálogo con la colección correspondiente igual de de puertos y haremos a
través del adaptador que accede al almacenamiento externo la carga de la
información de los elementos de esta de esta colección que maneja no
podemos ya todavía llamar o invocar al controlador del caso de uso porque
no hemos terminado necesitamos también el catálogo de productos o la
información correspondiente a todos los productos independientemente de en
qué puerto estén de todos los productos que se están manejando en el
caso de uso es decir, la colección de productos hidrocarburos que se
cargan en los tanques del correspondiente buque pues hacemos lo mismo que
antes no hace falta ni consulta específica condicionada o condicional, ni
nada se cargan todos accedemos a la factoría de servicios creamos el
adaptador del mismo almacenamiento porque todo está en el mismo
almacenamiento en una base de datos la información de todos los elementos
no tenemos por qué utilizar una base de datos distinta para cada una y si
fuera así utilizarían distintas fachadas para cada uno pero cada
adaptador sí que tiene que ser específico del que necesita acceder a ese
igual que tiene que ser especializado en ese elemento concreto de
almacenamiento externo que estemos utilizando para esta información bien,
pues una vez que hemos cargado aquí la creamos vacía una vez que la
cargamos con su contenido entonces sí creamos el controlador del caso de
uso donde le pasamos como argumento una copia del catálogo de buques del
catálogo de puertos y del catálogo de productos el gestor de cargabuque
el controlador del caso de uso de procesar cargabuque tiene a su
disposición las colecciones con información de los buques de los puertos
y de los productos accesible a él y a nada más que a él nadie otro son
componentes de esta clase de la instancia registro cargabuque otra cosa al
empezar los diagramas lo que se pone en cada caja son instancias de un
determinada de una determinada clase clase código ya no son conceptuales
aquí ya son todo clases de código lo que se coloca aquí es una instancia
así que todos tienen nombre de esa instancia y se pone el nombre dos
puntos vaya y la clase a la que pertenece todos todos todos todos si
nosotros tenemos una colección por ejemplo la colección de tipo de
elementos spec de vale esta es la clase bueno este es el objeto conceptual
que habíamos utilizado en el modelo de dominio y que va a ser el nombre de
la clase esta nombre de la clase es la correspondiente a uno de estos
elementos bien si uno de estos elementos es de tipo spec de producto pero
lo que estamos teniendo es una colección que se pone así con dos
cuadrados desplazados uno detrás de otro pues si quiero llamar a esto la
colección precios lo llamo nombre a la colección dos puntos y ahora aquí
no se pone el tipo o la clase de esta estructura de esta colección por
ejemplo si es un array list no se pone el tipo de el elemento es decir el
tipo aquí sería spec del producto no sé si me explico cuando estemos
representando aquí un multiobjeto aunque esté vacío se pone nombre de la
colección nombre de la instancia de esa colección ojo no distinguir entre
instancia de la colección y elemento de la colección vale el nombre es el
de la instancia de esa colección insisto le estoy llamando precios y aquí
sería la clase de la colección y no se pone la clase de la colección
sino la clase del elemento que sería spec esto independientemente de que
la colección sea del estereotipo hasma array list o como sea se pone el
tipo o la clase del elemento y el nombre de la colección que le estamos
dando a la instancia esa de la colección bien vale por entonces esto es se
llama c buques a la instancia de la clase catálogo de buques y todos
tienen que tener nombre servicio es del tipo adaptador base de datos buques
y este servicio acceso es la es el nombre de la instancia de la factoría
de servicios y así sucesivamente todos los objetos tienen nombre de la
instancia y la clase a la que pertenece y llegaríamos a esto que es
troceado antes esta sería la secuencia catálogo de buques catálogo de
puertos y catálogo de productos y por fin el registro de carga que sería
el controlador o gestor de carga el tipo o la clase que he definido en el
modelo de dominio y a partir de aquí estos tres catálogos instancias
insisto con sus correspondientes colecciones forman parte del del catálogo
este o del controlador del caso de uso y como forman parte sí que pueden
acceder a cada uno de esos catálogos no a la colección vale a cada uno de
esos catálogos y el catálogo le devolverá un elemento y con ese elemento
ya el controlador podrá hacer lo que le dé la gana o lo que necesite para
ir construyendo el resultado buscado en el caso de uso que tiene su clase y
tiene su nombre de instancia etcétera bien hay alguna pregunta el
siguiente paso sería empezar ya a definir de la misma manera que lo
estamos definiendo aquí o construyendo este sería el diagrama se llama
diagrama de interacción hay dos variantes el diagrama de los diagramas de
interacción el diagrama de secuencia por cierto en estos diagramas de
secuencia lo mismo que os he dicho lo de los nombres de todas las
instancias que se colocan en este diagrama de secuencia los mensajes o los
eventos siempre se sitúan en un punto de esta línea que se denomina se
denomina línea de tiempo puesto que digamos esto no puede ocurrir para
nada antes que esto o esto no puede ocurrir para nada antes que esto otro
no se numeran el orden en el que se producen las instancias suficientemente
explicativo y determinante en qué punto se está poniendo el mensaje para
indicar cuándo sucede una cosa y cuándo sucede otra la otra variante
estos serían los diagramas de secuencia que yo los llamo detallados en
este caso porque se pueden hacer como hemos visto de secuencia del sistema
globalmente situando la línea de tiempo del actor y el conjunto de todo el
sistema en este caso es gestflota esto sería un diagrama líneas de tiempo
diagrama de secuencia del sistema mientras que esto es un diagrama de
secuencia detallado vale, pues hay un diagrama de secuencia dentro de los
diagramas de interacción hay una modalidad que es esta la del diagrama de
secuencia y hay otra modalidad que es el diagrama de colaboración en estos
diagramas de colaboración no hay líneas de tiempo sino que se ponen de
forma lineal los mensajes y por ese motivo y su dirección desde quién
hacia dónde va por ese motivo por no haber líneas de tiempo es
imprescindible poner 1.3 por ejemplo un número de indexación una
numeración en el orden en el que se producen esos mensajes de
colaboración en los diagramas de secuencia no hace falta numerarlos bien,
para terminar hay alguna pregunta se ha quedado alguna cosa así en el aire
todo bien todo en orden vale os atreveríais a poneros a trabajar en el en
el diseño de la PEC o habéis en el caso de que estéis haciendo la PEC
claro el diseño no forma parte de la PEC me refiero a el trabajo final
empezar ya a hacer el diseño o con lo que llevamos viendo habéis
descubierto alguna deficiencia o alguna cuestión en como hayáis hecho el
modelo de dominio en la PEC o la escritura del caso de uso si, no solo hay
que mantenerlo simple sino digamos simple y puro en el sentido de evitar
esos acoplamientos que surgen a la mínima de cambio en cuanto uno se
despiste y por tanto sobre se ve con mucha yo creo con bastante facilidad
cuando me pongo a hacer el diseño como funciona me doy cuenta de que voy a
buscar un buque que estoy seleccionando el buque y como lo selecciono por
el nombre del buque y entonces como lo busco por el nombre del buque pero
es que entonces el nombre del buque es un atributo que tengo que irme
recorriendo toda la lista toda la colección elemento por elemento y mirar
si su atributo corresponde al nombre del buque que a lo mejor me he
equivocado al introducirlo insisto lo que haya en la parte de la interfaz
de usuario es una cosa que yo he podido poner un nombre pero al otro lado
la interfaz de usuario lo va a traducir en otra cosa lo que me importa es
esta cosa en lo que lo pueda traducir y esa traducción que es en lo que
voy a manejarme dentro del modelo de dominio va a seguir siendo el nombre
del buque en serio solo voy a tener que buscar en cada elemento hacer una
búsqueda o me doy cuenta de que efectivamente estoy buscando los elementos
de la colección para buscarlos, para seleccionarlos para modificarlos, etc
entonces lo que me resulta muchísimo más cómodo es manejar utilizar un
manejador un manejador que apunte directamente a toda la otra información
que yo estoy buscando y una vez que eso ya encuentro el elemento en sí con
toda la información y entonces ya si, manejo sus atributos y cuando me
pongo a a implementar en estos diagramas cómo funciona realmente esto es
casi como código pero casi súper cercano por eso no debería no debería
costar nada de aquí sacar el código lo curioso es que en muchos trabajos
se hace esto más o menos que tampoco está bien pero luego se construye el
código y se construye pues como se hacía en programación 1 entonces no
tiene nada que ver con todas estas separaciones que hemos hecho
anteriormente en fin, todas estas pautas que he estado hablando así que
bueno intentarlo y la semana que viene nos vemos muchas gracias y un saludo