Vale. Bueno, estábamos viendo cómo construir el modelo de dominio y
llegados a este punto, bueno, lo primero que quería hacer era preguntar si
había alguna duda. En este caso, a Jesús, que es el único asistente.
Pensaba hacer un pequeño resumen antes de continuar. Vale. Respecto al
trabajo final o al APEC con el final. Vale. Bueno, pues voy a hacer,
digamos, el resumen para aclarar ideas. Lo primero es que cada una de las
partes que voy a enunciar deben... Deben estar meridianamente claras porque
es que si no, todo lo demás es difícil comprenderlo. Hemos quedado en que
diseñar es definir cómo funciona un determinado elemento, una cosa. En
principio, vamos a ver el funcionamiento del software. Bien. Diseñar
significa, o sea, ese definir significa especificar. Y el cómo funciona lo
que significa es cómo ese elemento, sistema software o producto software o
lo que sea, cómo consigue el propósito, cómo llega a conseguir el
propósito para el que se ha creado o se está creando. O sea, la
intención... Para el que la que se está elaborando. Bien. Una vez
definido esto, pues diseñar. Realizar unas tareas sencillas, pues es lo
que se ha visto en distintas asignaturas como programación, algoritmia,
organización de los datos, bases de datos, etcétera, etcétera,
etcétera. Asignaturas que se supone que... Que ya se han visto. Esta
asignatura no es de ninguna de esas otras asignaturas. Su contenido no va
de eso. Y, por tanto, las técnicas que se ven ahí, en principio, tampoco
se están utilizando aquí. Estamos viendo cómo utilizar otras cosas para
conseguir eso. Hacer diseños. Pero no ese es el objetivo. No ese es el
objetivo de esta asignatura. Pero hay que dejar bien sentadas esas bases.
Que definir cómo funciona una parte o un sistema software, en principio
sencillo, que es lo que también se pide en esta asignatura. Es decir,
construir el código para que realice una determinada tarea, que sería el
sistema software que estamos viendo, los sistemas software que estamos
viendo, se puede hacer de muchas maneras, y entre ellas las que se han
aprendido en esas asignaturas que acabo de mencionar. Eso corresponde
directamente con el cumplimiento de los requisitos funcionales. Pero un
sistema software tiene o puede tener otros requisitos que no son
funcionales, que se podrían denominar requisitos cualitativos. Esos
requisitos cualitativos, pues, como pueden ser el mantenimiento, la
facilidad de mantenimiento, su capacidad de evolución y adaptación a
cambios en el mercado, etcétera, etcétera. Y de ahí, conjugando estos
requisitos funcionales con otros requisitos cualitativos, bueno, es algo...
Llegamos a... Unas características específicas de los diseños que
nosotros queremos hacer en esta asignatura, que son básicamente esos que
cumplen los que acabo de mencionar, unos requisitos cualitativos como
facilidad de mantenimiento, adaptabilidad, y eso se traduce en esa
independencia funcional, adaptabilidad o flexibilidad, y sencillez o
legibilidad o comprensibilidad, o sea, comprensible. Bien, estos aspectos
son los que van a orientar toda la asignatura y todo lo que estamos
diciendo por cómo construir el software de esta manera para que cumplan
precisamente estos requisitos. Entonces... A la hora de exponer los
distintos artefactos que llevamos viendo, el diagrama de casos de uso en la
fase de inicio, una visión global, la especificación de los requisitos,
la separación en distintos casos de uso, ese... Volviendo a la cuestión,
el definir... Volvemos al diseño. El definir cómo... Un sistema software
cumple o alcanza los objetivos o los propósitos por los que se está
creando o se está elaborando esos requisitos funcionales son lo que
denominamos... Los requisitos. Los requisitos funcionales, ese compendio,
son los que constituyen o la reunión de un conjunto de ellos son los que
definen una determinada funcionalidad o lo que estamos llamando aquí desde
el principio los casos de uso, que vienen a ser las historias de usuario,
etcétera, etcétera. Bien, el hecho de separar y ponernos a construir cada
uno de esos casos, los casos de uso, es simplemente una estrategia de
dividir el trabajo, pero responde a esta estrategia que se está utilizando
en todas las cosas que estamos viendo, que son separar cada parte sobre la
que estamos trabajando. Separar. Separar porque al final lo que estamos
intentando es... Hacer independiente cada una de las partes en las que
estamos trabajando de todo lo demás. Y eso es, digamos, lo más difícil
que parece... Lo que parece más difícil de comprender a la hora de hacer
estos desarrollos. Es una estrategia, pues haciendo un chascarrillo con el
dicho este que sale en las películas, lo que ocurre en Las Vegas se queda
en Las Vegas. Pues eso es, a fin de cuentas, lo que significa lo de la
independencia funcional. Que cada una de las cosas sobre las que nos
estamos centrando, bien sea para determinar cuáles son estos requisitos
funcionales, no tengan interferencias ni enmascaramientos por otras partes,
ni lo que se haga en otras partes repercuta en lo que estamos construyendo.
Y por eso esa obsesión, digamos, en separar una cosa de otra. El análisis
de lo anterior, aunque todo eso es hasta cierto punto ficticio, insisto,
como lo que estaba diciendo respecto a los casos de uso. El separar cada
caso de uso. Es algo artificial porque todo el software va a funcionar
conjuntamente. Esa separación que he puesto desde el principio y que hay
que tener en cuenta y que no se termina en muchos casos, los estudiantes de
esta asignatura no se termina de ver la separación entre lo que realmente
hace funcionar a estos casos de uso, lo que realmente o esencialmente hace
funcionar a estos casos de uso, que es lo que he denominado el código de
la capa del negocio o la lógica del negocio, separarlo de la interfaz de
usuario que quiere decir que las responsabilidades de hacer lo que tiene
que hacer cada caso de uso o la aplicación globalmente, etcétera, está
en este código. Y la interfaz de usuario no tiene responsabilidades sobre
ello, sobre esas cosas que tiene que hacer. Simplemente es un código cuya
responsabilidad es dedicarse a la entrada-salida, al formateo, a la
visibilidad, al acceso. De las interacciones de la información entre,
digamos, el exterior, esto, con la funcionalidad va a pasar por la interfaz
de usuario o lo que estoy llamando la capa de presentación. E igualmente,
diversas tareas de tipo técnico, de bajo nivel, incluso el acceso... A los
datos que están almacenados en algún sitio, pero a no ser que la
aplicación sea precisamente su objetivo, sea la gestión del
almacenamiento de determinados datos, en ese caso, ese es el negocio. Pero
en el caso de que no sea el negocio, el almacenamiento de los datos
persistentes, de forma persistente, es también interesante. Por lo tanto,
el código debe ser independiente o debe ser totalmente independiente,
ajena a esa responsabilidad, a las responsabilidades propias del caso de
uso. Y por tanto, ese código tiene que estar independizado. No quiere
decir que no se usen datos almacenados. Lo que estoy diciendo es que no
tiene responsabilidad sobre el almacenamiento de los datos. Bien. Eso que
estamos haciendo para... Separar ya el código y conseguir que sea
independiente, flexible, comprensible, para que cumpla esas cualidades, lo
estamos haciendo incluso... Y nos estamos refiriendo para que el código
haga esas cosas o tenga esas características. Bueno, pues lo estamos
haciendo incluso ya desde el planteamiento de la obtención de los
requisitos funcionales. En el modelo de dominio. Incluso en la escritura
del caso de uso, donde estamos evitando poner cualquier referencia a
subfunciones o aspectos técnicos de cómo es la entrada-salida, y eso es
lo que significa el estilo esencial de la escritura del caso de uso, e
incluso en el modelo de dominio. En el modelo de dominio, el cómo
representamos las estructuras de la información que estamos manejando,
donde ya, aparte de eludir totalmente cuál es la parte o el código que
debería hacer, las funciones que debería hacer la interfaz de usuario, o
las funciones que debería hacer el código correspondiente al acceso al
almacén de datos persistente, o el acceso a los servicios que se pueden
intercambiar con actores de apoyo externos, sistemas de apoyo externos al
sistema software que estamos construyendo. Bueno, pues eso también... Si
este es el... Si este es el sistema de apoyo externo, por eso es importante
definirlo en el diagrama de casos de uso, ese sistema externo también
puede interaccionar, o puede ser necesario que interaccione con la lógica
del negocio, con el código que estamos construyendo, en el que nos estamos
enfocando ahora, pero tiene que ser de una manera independiente, porque la
cualidad del código que estamos desarrollando exige que lo que hace esto
no interfiera, no haga dependiente a este código que estamos construyendo.
Esto quiere decir, dicho... Rápidamente, que si cambiamos este elemento
por otro, este funcionamiento tiene que seguir siendo el mismo. No
deberíamos o no tendríamos que cambiar el código correspondiente a la
lógica del negocio, porque esa lógica del negocio sigue siendo
invariante. Invariante frente a que, pues por ejemplo, en el caso del...
del libro el sistema de cálculo de impuestos que cambie de un país a
otro. Eso se externaliza al sistema que estamos construyendo. Así que el
código que estamos construyendo tiene que funcionar igual, tanto si es un
sistema externo para el cálculo de impuestos u otro, de otro país, por
ejemplo, u otros, o el de contabilidad, pues no lo podemos hacer
dependiente del sistema externo de contabilidad que estemos utilizando
para, pues eso, facturación, etcétera, etcétera. De manera que eso es lo
que queremos conseguir y aunque eso sea, digamos, el objetivo para el
código, el código que vayamos a construir aquí, que estoy repitiendo
muchísimas veces, numerosas veces, que esto no es código, sino que son
elementos de información con una determinada estructura, también tiene
que evidenciarse que el código sea de esta manera. Porque es que este
planteamiento del modelo de dominio Y es tan útil esta representación de
la información, aunque sea conceptual, es tan útil para construir el
diseño como que efectivamente con eso podamos construir ese diseño
específico con independencia funcional, flexibilidad o adaptabilidad y
comprensibilidad. En la medida que, ya digo, sea útil para construirlo
así. Si esto no se evidencia estas características que estoy diciendo,
luego en la traducción difícilmente podremos conseguir construirlo con
estas características. Así que es fundamental que aquí ya se observen
estas características, y por eso estoy explicando cómo se construye el
modelo de dominio de estas maneras que estoy diciendo. Bien, ya habíamos o
había dicho que una manera de, digamos, una secuencia para construir este
modelo de dominio primero era identificar cuál era el objetivo que quería
conseguir el..., a ver, cuál era el objetivo que quería conseguir el
actor al usar la aplicación. La otra cuestión es qué elementos de
información mantenidos internamente por la lógica del negocio, por el
sistema, se necesitaban para construir, para elaborar este resultado que
está buscando el actor. Era lo que ya yo llamaba el modelo de datos. Vale.
Otra cuestión a la hora de construir este modelo de dominio. Como digo, lo
que ocurre en el caso de uso se queda en el caso de uso. Digamos, vamos a
utilizar este... ... esta máxima como estrategia general en toda la
asignatura. Quiero con esto también justificar que efectivamente para
construir estos elementos, que ya digo, aquí en el modelo de dominio son
conceptuales, la información que estoy poniendo, aquí en estos elementos
del resultado buscado por el actor en el caso de uso, el actor que maneja
el caso de uso, habrá estructuras de información. Algo hemos hablado de
qué estructuras podemos asignar a esos elementos de información, pero
habrá estructuras de elementos de información que son, que se construyen,
que son intrínsecos, específicos de este caso de uso como son
efectivamente este resultado, la venta, toda la información que hay dentro
de la venta y la colección de ítems vendidos o de línea... la colección
de líneas de venta, esos son elementos que se construyen dentro
exclusivamente son específicos de este caso de uso. Por decirlo de otra
manera, cuando vayamos al código son clases e instancias correspondientes
de esas clases que son específicas y únicas dentro de esto. Fuera del
caso de uso o del código que se está utilizando, es otra de las razones
por la que queremos independizar el caso de uso de todo lo demás, fuera de
este caso de uso no existen ni se conocen, ni nada de eso. Bien, ahora es
posible en algún funcionamiento que también utilicemos, pues no sé,
objetos conceptuales o luego ya de código que sean auxiliares y accesorios
temporales, digámoslo como lo podemos llamar de muchas maneras en la
construcción de este caso de uso. Pero son específicos y no se usan en
ningún otro caso de uso. Vale. Pues eso también se supone que como se
crean aquí ad hoc para este caso de uso son independientes, no se conocen
en ningún otro lado, en ningún otro caso de uso ni en ni siquiera en el
gobierno. Acordaos que el gobierno es esa es ese código que regula, maneja
toda la el funcionamiento jerarquizado de toda la aplicación. La la
secuencia de cuando entra un caso de uso a funcionar cuando no, cuando en
fin otras muchas cosas de las que ya hablaremos y estamos hablando aquí.
Quiere decir que ya hablaremos en el cuando construyamos el diseño y el
código y que ya estamos hablando aquí cuando estamos modelando el negocio
desde el punto de vista conceptual. Que también lo tenemos que tener en
cuenta. Vale. Y en tercer lugar hay otra serie de elementos estructuras de
información que se traen o si utilizan transversalmente en distintos casos
de uso o o no pero la información correspondiente a determinados elementos
sí que se utiliza transversalmente y en varias partes de el funcionamiento
del software general en fuera del caso de uso. ¿Qué hacemos con esos
elementos de información que se utilizan en otras partes de lo que es la
aplicación y además lo necesitamos en el funcionamiento de digamos
nuestro caso de uso que insisto queremos que esté totalmente aislado. Muy
bien. Pues ¿cómo lo hacemos? ¿Cómo conseguimos esto? Pues los elementos
que correspondan se copian se hace una copia y se incluyen en el ámbito
del funcionamiento cerrado y aislado de el caso de uso. De manera que una
vez que nos lo traemos aquí ya pero insisto es una copia no es lo que
forma parte no son los datos originales digamos del que se utilizan en
distintas partes sino una copia que sólo se va a utilizar aquí de manera
que lo que hay que pensar es que en el código todos este elementos que se
van a traducir luego a código van a estar en memoria por supuesto esto que
sigue siendo la capa de negocio esto que se utiliza en este elemento de
información que se utiliza en distintos casos de uso o por el gobierno de
la aplicación en fin qué es de uso comunitario de la aplicación o el
software que estamos construyendo no es el almacén persistente no es el
almacén de datos eso hemos quedado en que necesariamente puesto que nada
de la funcionalidad de la aplicación que el almacenar o leer de un
almacenamiento persistente es esa información esos datos pues eso estará
independiente lo pinto así o lo pinto así está independiente de la capa
de negocio por tanto esto no es esto no es almacenamiento persistente de
ninguna manera pero es más para conseguir aislar el caso de uso esto que
no es almacenamiento persistente que insisto que está en memoria en alguna
estructurado de alguna manera organizado de alguna manera tampoco lo uso
directamente sino que lo que uso así que estas estructuras que estoy
haciendo aquí son todas ad hoc son todas específicas y me las organiza
como yo necesite para qué se me sean me resulten útiles para construir
ese resultado que yo estoy buscando en el caso de uso y a la vez para que
esa elaboración o construcción de ese resultado no signifique un uso que
produzca acoplamiento o una cohesión baja es decir que estas estructuras
de todos estos objetos deben ser con acoplamiento bajo o débil con
cohesión alta tienen que ser permitir la flexibilidad en su sistema
especificaciones modificación de la en fin una serie de características
que las estamos viendo específicamente en esta asignatura de manera que ya
he dicho que esto es ad hoc esta estructura esta información o sea que
cuando hacemos el modelo de dominio construimos el modelo de dominio
primero lo que no primero nos fijamos es en dotar a la identificar la
información que constituye el resultado que está buscando el actor en ese
caso de uso segundo darle una estructura que sea compatible con cómo se
podría elaborar los pasos que son necesarios para elaborar ese contenido
segundo determinar ese contenido aparte del que pueda aportar el actor como
puede ser en este caso de pdv y procesar venta pues la cantidad el producto
en sí las características del precio y eso de dónde proviene entonces
pues está claro que eso proviene de una información que se maneja dentro
del negocio de la pdv de la tienda del punto de venta que es ese precio de
la información las características correspondientes al producto son
utilizadas transversalmente dentro del caso de uso de procesar venta pero
también puede ser dentro del caso de uso de gestionar devoluciones o
dentro del caso de uso de adquirir nuevos adquirir el mantenimiento del
inventario adquirir nuevos productos etcétera fin los distintos casos de
uso o la funcionalidad que pueda tener esta capa de negocio de manera que
entendido esto es fundamental entender el por qué organizamos la
información aquí de esta manera porque está definiendo luego cómo
hacemos el diseño es decir definimos el funcionamiento del código como
estamos obligados a definir el funcionamiento del código de esa manera con
acoplamiento bajo etcétera acoplamiento bajo adaptabilidad
comprensibilidad sencillez con esos tres aspectos cualitativos es
fundamental pensarse mucho cuál es esta estructura que estamos dando para
evidenciar precisamente que cuando luego vayamos al código pues lo podamos
construir así de la mayoría de las otras maneras así y entonces da un
fracaso en cuanto a la consecución de estos objetivos que estamos buscando
en nuestros diseños un error muy común es que al estar pendiente de
conseguir definir el funcionamiento del código de esta manera que acabo de
decir el código que se define ni siquiera es capaz de cumplir los
requisitos funcionales es decir el código que se define ni siquiera es
capaz de conseguir construir ese contenido de el resultado que está
buscando el actor hay que tener mucho cuidado con esto porque generalmente
es una fuente de numerosos fracasos en cuanto a la evaluación hay que
aprender a construir el código de esta manera que se supone una cosa
sencilla que se sabe por programación y por otras muchas disciplinas que
ya se están se han visto dentro de la carrera y saber conjugarlo con
hacerlo de estas maneras que estoy diciendo para conseguir esos objetivos
adicionales pero que son los únicos y fundamentales de esta asignatura la
independencia funcional es decir el acoplamiento bajo vale entonces la
cuestión es antes que nada observando ya hablé el otro día en qué casos
en qué casos utilizar digamos lo que el libro aunque es que es un poco
ambiguo ese los términos que utiliza el libro unas veces se refiere a él
a la descripción del producto y lo llama especifica la descripción del
objeto que estamos manejando en sí os recuerdo para construir el resultado
de cada ítem vendido que constituye elementos de una colección de ese
resultado de la venta que es venta el objeto conceptual es venta se
necesita saber el precio forma parte de la información de una colección
de productos colección de productos del de cada uno de esos elementos una
vez determinado el producto del que se trata obtendríamos su precio es
decir esta colección digamos que es una información inherente y necesaria
para construir este elemento el resultado que está buscando el actor ya
dije el otro día que para este caso lo único que estamos necesitando es
pues una pequeña descripción porque nos va a aparecer como información
al cliente al usuario en este caso al cajero de qué se trata y sobre todo
su precio para determinar en cuanto a la cantidad de productos que se de
artículos que se está llevando que está comprando determinar cuánta
cuál es la cuantía ya estuvimos hablando que de la información asociada
a los productos que están en venta o que se venden atributos de
descripción precio del artículo ya identificador del objeto ya hablé la
semana pasada pero de momento vamos a obviarlo asociado a lo que es el
producto en venta puede haber un montón de información adicional que
seguramente está almacenada persistentemente pero para esto sólo
necesitamos de manera que la descripción lo que llama el libro
descripción del objeto en este caso del producto en venta o la
descripción de los precios o del precio del producto lo podríamos llamar
de distintas maneras la descripción sólo necesita esta información
insisto esto estará en memoria el código y es algo que se hace ad hoc
para independientemente de todos los datos que pueda haber sobre un
producto en la base de datos en los ficheros o en donde sea es
independiente pero para esto sólo necesitamos esto así que esto lo vamos
a fabricar ad hoc exclusivamente para este caso de uso la controversia es
que de la descripción de un objeto utilizar un manejador la cuestión es
que luego cuando nos vamos al código pues ya he dicho que el actor le va a
llevar vamos a poner aquí el sistema le va a decir que al sistema por
ejemplo agregar producto esto sería ya si no cuando estamos descomponiendo
esto y aquí está la interfaz de usuario le podría decir nombre vale la
cuestión es qué es nombre voy a ponerlo así descripción objeto en el
caso de que fueran productos pues podría decirle este es ese es el nombre
la otra característica que voy a utilizar vale pues el precio o en el caso
de uso que sea pues lo que sea si yo utilizo nombre posiblemente el nombre
sea significativo para el objeto para el objeto que engloba todos esos
objetos lo voy a llamar el controlador cuando le llega aquí el nombre no
es más que un objeto para el código que puede ser un atributo o puede ser
lo que sea lo que quiere decir es que este nombre de aquí para allá sí
que tiene un tipo es decir la significación que puede tener nombra para el
actor es relevante al otro lado a la izquierda de la iu y es relevante para
el actor pero como estamos viendo el funcionamiento del código nombre por
mucho que tenga un significado para el actor nombre aquí dentro dentro de
el código de la lógica del negocio de la capa del negocio nombre no es
más que un elemento de información tipo si es un atributo cuando llega
aquí el controlador tiene que saber que esto es el atributo de un
determinado objeto que es de una determinada clase es lo que quiero decir
entonces dependiendo de lo que tenga que hacer ahora con esta información
con este dato nombre el controlador del caso de uso hará determinadas
cosas con objetos con instancias de determinadas clases que para que sean
accesibles tienen que ser componentes elementos componentes de este
controlador no puede acceder a cualquier objeto si no lo tiene incluido
puesto que una de las características del funcionamiento de los objetos es
que los métodos que tengan sus funciones sólo pueden acceder a la
información que contienen no a ningún otro objeto bien pues sin hombre
resulta que es un atributo de un determinado objeto con esto queramos
seleccionar un elemento de un multiobjeto y cuando hablemos de código y de
cómo se representan las instancias en los diagramas de interacción de
este tipo que es el diagrama de secuencia o los diagramas de colaboración
que también son de interacción y donde se está viendo el funcionamiento
del código ya cuando lleguemos a este tipo de diagramas un multiobjeto es
decir un elemento un objeto que tiene que está constituido por una
colección de objetos se pone con una caja con un objeto se pone de esta
manera ya os lo enseñaré bien cuando vaya a identificar cuál de todas
estos elementos de esta colección de este multiobjeto cuál es el que
quiere seleccionar o quiere que un componente de el objeto desde el que se
envía el mensaje de otra manera no puede acceder a esta funcionalidad a
esta función a este método si lo que quiere es seleccionar por el nombre
tiene que ir recorriendo cada uno de estos elementos y preguntando si este
valor del nombre coincide con el valor de este atributo que se supone que
se tiene que identificar de manera que esta forma de trabajar es bastante
más engorrosa que el utilizar un una clase con un identificador abstracto
que no es ni nombre ni en fin no tiene ninguna significación sino que es
un identificador en este caso pues estamos trabajando con el producto pues
del producto que tiene un valor ya os dije que ponerlo así permite
desacoplar y aislar el acoplamiento que podría haber entre ese
identificador y su tipo y la información que se mantiene del elemento
entonces es bastante más útil simple y aparte de facilitar ese
acoplamiento débil el utilizar este abstracción este identificador de el
elemento para seleccionar ese elemento del cual pues en este caso de
procesar venta extraeremos luego si el atributo de su precio de acuerdo
pero para hacer manipulaciones con los elementos digamos que a raíz de
esto con esta en este sentido viene esa controversia de qué utilizar el
objeto el representante del objeto que es lo que aquí he llamado
identificador clase identificador con un atributo que será la
identificación ese valor de identificación o utilizar el las propiedades
o la descripción del objeto en sí para referirnos a un elemento dentro de
una colección no sé si me estoy explicando lo que estoy queriendo decir
es que a la hora aunque en el modelo de dominio se pone así con la
descripción del objeto que forma parte de una colección cuyo información
contenida va a ser necesaria para construir el resultado del caso de uso la
utilización por ejemplo de el atributo descripción en este caso el esto
sería la descripción del objeto y esto sería el representante esta clase
separada para evitar el acoplamiento separada del objeto donde el manejador
es lo que estoy denominando representante pero en realidad es un manejador
de esa de ese objeto que necesitamos manejar en el caso de uso vale pues
este manejador si no se utiliza es mucho más complicado luego en el
código realizar las operaciones por ejemplo de precisamente manejar el
elemento concreto dentro de una colección para la labor que se quiera
hacer dentro del caso de uso así que la cuestión es que tenemos una
multiobjeto cada uno de los cuales que podemos utilizar para depende de lo
que queramos hacer dentro del caso de uso si en el caso de uso necesitamos
utilizar un elemento concreto que lo utilizamos de manera importante o sea
de manera fundamental para construir el resultado que estamos buscando en
el caso de uso de podemos ir a buscar directamente el elemento constituido
por todo su contenido toda la descripción del objeto todos esos atributos
que vamos a utilizar o es mucho mejor utilizar un una abstracción que
representa a un objeto lo que estoy llamando un manejador de ese objeto que
sería en este caso artículo id cuyo valor es el que vamos a utilizar para
manejarnos para seleccionar un elemento para de ese elemento ya traer
extraer la información que es recomendable precisamente para estos casos
intento aclararlo qué casos los casos en los que necesitan tenemos una
colección de objetos y necesitamos manejar algún elemento de esa
colección de manera fundamental dentro del funcionamiento para contenido
del resultado del caso de uso me he explicado vale la otra cuestión que es
la sobre lo quería a ver cuando hablo de objetos aquí en el ámbito del
modelo de dominio en el ámbito de la escritura del caso de uso que vamos
ahí sí que no hablo de objetos pero cuando hablo de objetos pues por
ejemplo aquí en el modelo de dominio son objetos conceptuales y lo que
estoy diciendo es que estos objetos conceptuales los construyo de esta
manera porque luego el código se va a comportar pues como se comporta el
código es verdad que estos objetos conceptuales tienen cierto
comportamiento de objetos de código en el sentido de que sólo pueden
manejar esto que estoy diciendo que tienen dentro sólo pueden manejar sus
atributos en realidad este modelo de dominio está definiendo la lógica
del funcionamiento aunque sea conceptual de una manera implícita porque si
yo digo que esto es un objeto conceptual tiene esta información estoy
tendrá unos métodos que manejen esta información y sólo van a poder
manejar esta información igual que el si este catálogo de productos
contiene una colección de objetos especificación del producto del
producto este objeto conceptual catálogo de productos sólo va a poder
manejar eso sólo va a poder manejar los elementos de o sea la colección
porque es lo único que contiene una colección de elementos spec de
producto no va a poder manejar el precio este catálogo de productos sino
los elementos única y exclusivamente porque es lo único que contiene por
eso es muy importante en el modelo de dominio que las relaciones se
refieran a qué contiene o de dónde proviene la información que se va a
utilizar sea línea de venta no tiene ningún elemento del producto sino
que la información que se va a meter aquí proviene de y eso es lo que
indica esta relación proviene de este elemento mientras que tienda que es
el controlador de nivel superior en la jerarquía del funcionamiento
contiene el catálogo de productos es un elemento suyo el registro de
ventas que es el controlador del caso de uso aquí lo de abastece no tiene
ningún sentido simplemente es para dar una idea de qué es lo que provee
pero todas las relaciones se corresponden a o de dónde proviene la
información que se utiliza para construir el resultado o qué información
está contenida en qué objetos para poderse manejar lo que estaba diciendo
antes y qué es lo a ser la posible funcionalidad de un elemento de este
producto porque esto aunque sea un objeto conceptual se va a comportar con
los métodos que sea que todavía no lo hemos definido se va a comportar en
el código como que los métodos sólo van a poder manejar artículo id
precio y descripción y punto y no van a poder hacer nada más y los
métodos que hay aquí dentro del catálogo de productos sólo van a poder
manejar la colección obtener un elemento de la colección pues a lo mejor
añadir un elemento a la colección borrarlo modificar algún elemento
etcétera o invocar la modificación dentro de ese elemento concreto
entonces el modelo de dominio aunque estemos utilizando objetos
conceptuales que no son objetos de código de ninguna de las maneras
primero las relaciones no pueden significar ni tienen que tener nombre que
signifiquen una acción excepto las que provienen del del actor que maneja
el caso de uso porque ese sí tiene una voluntad de hacer de realizar
acción pero pero no el resto de las funciones aunque tengan verbos pero no
significan esos verbos no pueden significar ninguna acción en la
realización de la funcionalidad asumida así que la funcionalidad deseada
que es lo que se define en el modelo de dominio en este diagrama conceptual
se manera se define de forma implícita diciendo con estas relaciones qué
objeto está dentro de qué y cada objeto qué información tiene para
saber qué es lo que se maneja ahí en ese objeto que es lo único que
puede hacer se está definiendo esa funcionalidad de una manera implícita
diciendo cuál es el contenido de la información contenida en eso me he
explicado esto suena pero no aparece eso es pero no se puede poner aquí
nada de objetos ni de código en el modelo de dominio no se puede hablar de
nada de código aunque se construyen así los objetos conceptuales porque
efectivamente con algún hemisferio raro cerebral estamos pensando en que
eso luego va a ser código y se tiene que comportar como nosotros estamos
queriendo de manera desacoplada y con cohesión alta etcétera y eso nos
fuerza a que la definición implícita no cualquiera y por eso digamos que
muchos de los modelos de dominio que se construyen sin entender esto son
defectuosos porque no indican para nada cómo construir cómo se va a
elaborar ese el contenido de ese resultado que busca el actor para empezar
y por y para continuar aunque si lo describan la manera que implícitamente
están diciendo es que se hace esa construcción del resultado
necesariamente va a llevar a unos acoplamientos que son absolutamente
inaceptables que no se pueden tolerar en este en esta asignatura cuyo
objetivo es ver a ver cómo construimos el código de manera que funcione
de esas maneras funcionalmente independiente adaptable etcétera de acuerdo
vale pues continúo el objetivo era hablar de otra cuestión que resulta
muy complicado de entender parece ser de los catálogos el uso de los
catálogos ha quedado claro el por qué utilizar las características de un
determinado objeto que forma parte de una colección o no pero que se va a
utilizar en el funcionamiento y utilizar la descripción del objeto o la
utilización de el representante o lo que yo llamo manejador de ese objeto
claro en qué casos conviene utilizarlo y en qué casos no o no hace falta
vaya que es importante a la hora luego de construir el código como
nosotros queremos vale pues ahora la siguiente el siguiente paso para este
esta esta estructura que ya os digo que parece que produce bastante
controversia en los primeros días dije a ver para calcular cuánto cuesta
cuatro condensadores de 47 microfaradios y yo que sé en fin con las
tolerancias o cerámicos en fin con las características que tenga qué
qué es lo que necesito el planteamiento es bueno pues un cliente llega a
caja y pide o muestra esos condensadores cerámicos de 47 microfaradios
etcétera vale para registrar esa línea de venta o ese ítem vendido qué
es lo que necesita el sistema para registrar esa información
correspondiente desde el punto de vista conceptual vale el número de
ítems el cliente dice pues me llevo estos cuatro de estas características
vale necesitamos el precio el cajero o el si el que está en caja o el
sistema que tiene que funcionar automatizando esta tarea tiene que saberse
de memoria los precios de todos los elementos de todos los productos que
tiene a la venta en la tienda qué necesita entonces para anotar ese
elemento de dónde saca la información que necesita un listado vale ese
listado imaginaos que lo hacéis con tarjetitas vale tenemos aquí una
tarjetita un post it el precio de los condensadores cerámicos de 47 el
precio del vale qué problema tiene el que tengamos post it para cada uno
de los tipos de condensadores que hay su valor igual para las existencias
para los transistores etcétera vale no sólo eso sino que si cada uno de
estos elementos este post it está en un sitio recopilarlo y buscarlo
efectivamente dejamos que imaginémonos que todos los productos los tenemos
metidos en sus cajitas y las cajitas pues ahí mismo le ponemos el post it
o una etiqueta diciendo el precio es una cosa muy común para calcular el
precio pues me tendría que ir hasta ahí si intercambiar al cajoncito
donde están los condensadores cerámicos de 47 microfaradios etcétera
para obtener el precio qué creéis qué resolvería esta situación
ineficaz absolutamente la de tener los productos en tarjetas vale más que
nada se trata de compilarlos visto así desde el punto digamos más real
más encuadernarlos diría yo bueno creo que me estoy saliendo fuera de los
límites de la grabación encuadernarlos de ellos pero esa encuadernación
está mediatizando también el uso que quisiéramos hacer de estos precios
porque aquí las hojas una vez encuadernadas que serían estos post it vale
esos los precios como los colocamos para buscar el precio por ejemplo los
colocamos por orden alfabético los organizamos por categorías de
componentes si queremos cambiar el precio de uno o hemos cambiado de
fabricante proveedor y queremos cambiar el precio o determinadas
características de ese elemento que hacemos con toda la encuadernación
muy bien esa es una solución que tengamos una flexibilidad usando tipex y
cambiamos el precio y ya está vale lo que a lo que voy es que vamos a ver
ahora vamos a pensar en el comportamiento del código si nosotros tenemos
una estructura de código donde compilamos todos estos elementos por
ejemplo pensar en un arraylist vale si todos esto lo juntamos en una
estructura que se llama arraylist podemos hacer determinadas cosas que son
los métodos como se llaman los métodos nativos de esta estructura como
por ejemplo recorrer toda el los elementos del de la estructura del
arraylist incluso ordenar en distinto orden podemos recolocarlos en
distintas posiciones para digamos su accesibilidad es decir hay unas
funcionalidades que vamos a denominar primitivas que son las que restringen
el cómo utilizamos esa colección de elementos y qué podemos hacer con
ello si queremos hacer otra cosa que no sea las primitivas de este
arraylist imaginaos que este arraylist lo llamamos precios vale pues con el
arraylist precios podemos hacer determinadas cosas estas primitivas pero si
queremos hacer otra cosa ya nos vemos limitados y no podemos hacer nada
más tendríamos que escribir un código adicional que utilizando las
primitivas y otras cosas actuará sobre esta colección a este otro código
en qué objeto le corresponde es decir tiene que haber un objeto que tenga
el código para o en el que tendríamos que implementar el código para
manejar la estructura que hemos definido con los elementos de esa
colección o sea los elementos que o manejar no no se llama controlador se
llama catálogo así que el catálogo contiene toda la colección y además
tiene el código necesario para manejar los elementos de esa colección por
encima de las primitivas que tenga esa estructura concreta de la colección
de manera que cuando queremos hacer ese tipo de cosas es decir manejar los
elementos de una colección por encima de la estructura o de los métodos
primitivos por eso lo llamo catálogo guión manejador porque un catálogo
es el que se ocupa de manejar la colección por encima de o sea de una
manera más amplia y por tanto más útil para lo que podamos querer hacer
en este caso de uso os recuerdo esta colección es específica para este
caso de uso pero le tendremos que dar una estructura y esa estructura sólo
nos dejará hacer unas determinadas cosas las primitivas para querer hacer
porque de ello depende el que construyamos este resultado para querer hacer
lo que queramos hacer con la colección en algunos casos ese manejador de
una colección de los elementos de una colección es lo que denominamos
catálogo así que siempre que tengamos una colección no es siempre
necesario que la manejemos con un catálogo pero en algunos casos sí es
necesario que utilicemos un catálogo y en otros casos dentro de un caso de
uso que estamos manejando elementos de una colección es absolutamente
innecesario utilizar un catálogo me he explicado vale por ejemplo la venta
contiene una colección de ítems vendidos ahí necesitamos un catálogo
sí bueno me estoy refiriendo a este caso tiene una colección de ítems
vendidos o sea esto los ítems vendidos es una colección si se lleva
condensadores no sé cuántas resistencias y tres transistores pues tenemos
tres elementos podríamos considerar que la venta que es el contenedor de
esta colección es su catálogo vosotros creéis que venta es su catálogo
en realidad no no es más que eso es menos incluso porque la venta lo que
hace es crear un ítem y lo va añadiendo y lo va añadiendo apenas hace
nada con ello es decir que va apilando los elementos y luego lo recorre
para calcular el total seguramente o lo recorre para ver pues por ejemplo
qué tipo de impuesto tiene cada uno en el caso de que cada uno elemento
tuviera diferencias de fiscales de impuesto yo que sé que tuviera uno un
iva no hace nada más entonces vale lo podemos considerar un manejador pero
no llega a esa categoría de catálogo lo estoy explicando todas estas
cosas pues para que veáis porque no hace falta poner catálogos en todos
los elementos de la colección que contengan esa colección y manejen
específicamente esa colección por determinadas cosas y sobre todo por
digamos esa imagen de la estructura general sin salirme de la capa del de
la lógica del negocio y de todas estas cosas lo que os decía de que hay
que definir también la arquitectura de o sea la descomposición modular de
todos los elementos de la capa de negocio también hay que organizarlos en
una arquitectura que tiene que ser con acoplamiento débil con cohesión
alta etcétera vale pues para que en qué casos es conveniente e incluso
necesario aquí en el modelo de dominio definir qué elementos de una
colección necesaria para construir el resultado del caso de uso en qué
cuál de esas colecciones es necesario utilizar un manejador catálogo y en
cuáles necesidades es necesario que las colecciones tengan su catálogo ni
que las colecciones no se utilicen con un catálogo o no tengan un
catálogo que las maneje según la necesidad y eso es lo que estoy
justificando cuando hay necesidad en este caso que ya digo que los
catálogos una colección son elementos de una colección de venta y lo que
hace el único que hace la venta como manejador es ir apilando uno con otro
dentro de una colección que contenida en la venta pero no hacen nada más
sin embargo si lo que necesitamos es un tratamiento mayor e incluso otras
cosas que voy a explicar a continuación en ese caso sí que necesitamos un
catálogo y luego está en el caso de que estemos utilizando diversas
colecciones en cómo organizar esas colecciones y la información que viene
detrás pero voy a terminar de hablar de cuándo se necesita este catálogo
y cuándo no como decía pensando en aquí no sé si veis este si hay poca
definición en este en esta gráfica en este dibujo como os decía cuando
pensemos en el los objetos de código las clases etcétera en el
funcionamiento global que es lo que estamos denominando el gobierno de el
software que estamos construyendo por encima de el funcionamiento de cada
caso de uso también tenemos que definir cuál es la arquitectura de de ese
código cuál es la arquitectura la descomposición en módulos para datos
o para información que se utiliza transversalmente vamos a ver aquí
tendríamos otro paquete que sería el de ventas vale y aquí dentro del
paquete de ventas pues pues no sé tendríamos la venta la línea de venta
en fin distintos elementos vamos a poner aquí el controlador referente y
el registro también para construir esto que está en un paquete en un
módulo dentro de el negocio está en un módulo separado de este paquete
que es el de productos venta para conseguir una alta cohesión en este
módulo vamos a meter no sólo los elementos con los precios del producto
la especificación del producto que insisto esto es una colección vale
sino todo lo que maneja está esta información de especificación del
producto así que en este módulo para conseguir una cohesión alta vamos a
tener que meter todos los elementos que manejan esta información esta
información y funcionan aquí con esta información aislada de manera que
esta información se va a manejar en otros sitios pero de una manera
mínima la más pequeña que sea así que en qué módulo de la
arquitectura dentro de la capa de negocio insisto esto es la capa de
negocio la IU está por ahí fuera el acceso a los datos está aquí en
otra capa aislado totalmente de ello si nosotros necesitamos hacer cosas
con el objeto especificación de producto con los elementos de esa
colección que cómo lo vamos a utilizar y en qué módulo de la
arquitectura de la capa de negocio va a tener que estar ese objeto para
conseguir una cohesión alta no en el gobierno no en el gobierno vamos a
ver lo que hay en el gobierno como a ver el gobierno es todo lo que hay
fuera de estos de estos módulos vale digamos el gobierno es donde ponemos
el main de toda la aplicación pero dentro de esta argamasa que está
dentro del negocio y que se dedica a manejar todo lo demás tendremos
paquetes o módulos o componentes de la arquitectura cuyo funcionamiento
tiene que ser independiente desacoplado de el funcionamiento de otros
módulos cada uno de esos módulos como por ejemplo producto venta
productos venta lo que ocurra o los objetos el funcionamiento de los
objetos que están dentro de este módulo tiene que estar desacoplado del
funcionamiento de los objetos que colocamos en otro módulo los objetos que
hay dentro largamasa esta que que estoy diciendo del gobierno de toda la
aplicación seguramente en algunos casos tendrán acceso a todo el mundo a
este paquete a este paquete al otro paquete vale esos son los únicos que
se le permite acceso a todos los demás porque son del gobierno ahora lo
otro fuera del gobierno tendremos que agrupar los objetos en determinados
módulos y esos módulos su funcionamiento o los objetos que están dentro
de esos módulos su funcionamiento tiene que ser independiente del
funcionamiento de los objetos que están en otro módulo en otro paquete
porque si no estarían acoplados queremos acoplamiento bajo entre los
elementos dentro de un módulo entre un módulo y el otro entre la capa de
negocio la capa de la iu y la capa de acceso a datos queremos
desacoplamiento en todos así que si yo además dentro de un módulo los
objetos tienen que tener la mayor cohesión posible un objeto que coloque
aquí no puede estar manejando cosas qué pertenecen a otro módulo así
que la cohesión tiene que ser alta dentro de este módulo si yo necesito
manejar los elementos de este esta colección de elementos de esta
colección en qué módulo colocaré el catálogo para que haya una máxima
cohesión con esos la información que manejan es que están en esos
elementos y a su vez sea independiente del lo que del funcionamiento de los
objetos en otros módulos no no no no no vamos a ver yo tengo un módulo a
ver voy a pintarlo otra vez yo digo voy a manejar la información de los
productos y esa información de los productos la voy a meter en el módulo
componente o paquete dentro de la arquitectura productos venta sí para
conseguir que si yo necesito para manejar esta colección en los elementos
de esta colección si yo necesito un catálogo para conseguir que sea que
tenga la máxima cohesión con estos elementos de producto venta y cuyo
funcionamiento sea independiente de lo que haya en otros módulos
independiente de lo que haya en otros módulos donde lo colocaré para
manejar esta colección de especificación del producto no sé si me
seguís vale efectivamente os acordáis a lo mejor es que estoy manejando
términos que no os acordáis lo que significan cohesión os acordáis lo
que es vale y acoplamiento alto o débil también vale bueno más o menos
pues acoplamiento es la injerencia que del funcionamiento de un objeto un
objeto hace determinadas cosas estos son los atributos y estos son los
métodos un objeto hace determinadas cosas con sus con sus atributos o sea
tiene unos métodos que maneja determinados elementos el acoplamiento es el
grado de injerencia la intervención de un objeto con respecto a otro
imaginémonos que estos elementos a tal es así que no no se puede porque
si este objeto no tuviera nada que ver imposible que este método manejara
los los atributos de este otro debido a al encapsulamiento y la ocultación
que existe entre los objetos de tipo código de acuerdo ahora y si éste
fuera un componente es decir éste fuera uno de los atributos de este
objeto pues este método podría acceder a este objeto y por tanto invocar
alguno de de sus métodos y si esos métodos hicieran modificaciones pues
ahí tendríamos un acoplamiento en el contenido de este objeto ahí
tendríamos un acoplamiento un acoplamiento donde dependiendo de qué es lo
que haga si tendría una repercusión y sería un acoplamiento fuerte en el
caso de que el funcionamiento de este elemento o de éste de este objeto
depende del funcionamiento de otro e interviene en la modificación de su
contenido de manera que si queremos hacer cambios en uno necesariamente se
tienen que modificar el código en un objeto que está acoplado con el otro
necesariamente se producen necesariamente hay que hacer modificaciones en
el código del otro y eso es por lo que el acoplamiento fuerte es malo así
que buscamos que el acoplamiento sea débil es decir que el funcionamiento
de este módulo no afecte al funcionamiento de otro módulo que haya por
aquí y la cohesión es que haya un tratamiento de de la información que
se está tratando sea homogénea entre los distintos módulos o elementos
de un determinado objeto o de un determinado módulo componente o como
queramos llamarlos a estas agrupaciones de objetos dentro de la
arquitectura vale así que queremos que la cohesión dentro de un elemento
sea el que sea un objeto o sea una clase o sea un módulo la cohesión sea
alta y que el acoplamiento entre los objetos o entre los componentes o
entre los módulos de la arquitectura sea débil eso es lo que queremos o
bajo acoplamiento bien dicho esto si queremos si estamos tenemos la
necesidad de manejar los elementos especificación de producto que forman
parte del módulo productos venta productos y necesitamos poner utilizar un
manejador un controlador un catálogo donde situaremos ese catálogo para
que la cohesión sea la más la máxima posible si el catálogo lo que
está manejando son elementos de esa colección especificación de producto
elementos de producto información del producto dónde vamos a colocarlo en
qué módulo en productos venta de acuerdo todo el mundo está de acuerdo y
ha entendido esto vale es que bueno ahora eso es así con todo continuamos
con todo este razonamiento a ver borró esto esto es así a pesar de que
como os he dicho antes en el módulo otro módulo distinto de ventas donde
desde luego va a estar la venta y por supuesto el línea de venta o sea el
resultado que se registra del caso de uso ventas y si queréis pongo aquí
también el registro que voy a llamar registro ventas vale para construir
esto voy a necesitar esto de aquí verdad y esto está en un módulo y
hemos quedado en que esto está en otro así que este resulta que tendría
que transgredir los límites de su módulo de la arquitectura meterse en el
módulo de productos venta para construir este resultado eso lo veis un
acoplamiento pues es es un acoplamiento en efecto como evitamos esto y hay
más todavía es más bueno se me va a terminar el tiempo todavía es más
no no no no para nada todavía es más grave la cuestión cómo hacemos
esto vale pues es que lo que os digo es que el gobierno este elemento que
en el modelo de dominio he llamado tienda el gobierno de toda la
aplicación lo que hace os he dicho antes este el gobierno el que está
jerárquicamente por encima de todos estos el controlador que
jerárquicamente está por encima de las ventas este que está en el en
dentro del negocio pero en el gobierno tiene acceso a todo el mundo
entonces qué hace vale pues lo que hace es toma este catálogo de
productos que contiene toda la colección y se lo enchufa al controlador
del caso de uso no le enchufa este catálogo de productos sino una copia de
él así el el controlador del caso de uso registro venta ya tiene acceso a
una copia del catálogo de productos que contiene toda la colección de
especificación de productos y a partir de ahí eso es el elemento de nivel
superior lo que hace es tomar el catálogo de productos y se lo enchufa o
vamos a ver eso sería el mensaje vale créate y le mete el catálogo la
copia productos o sea hace un new registro o sea un nuevo registro vale
este sería el mensaje y esto es pues el la sentencia el el nuevo registro
que lo crea este hace un new de registro ventas qué es esta esta clase y
le mete en su constructor el catálogo de productos que es una copia de
este catálogo de productos que contiene esta elementos de la colección de
especificación de productos así que lo que haga el catálogo de productos
se va a quedar aquí siempre y yo me lo llevo aquí y estoy utilizando los
métodos de esta clase aquí en el catálogo de productos que estoy
manejando dentro de el caso de uso del paquete ventas esos métodos están
manejando los elementos del catálogo de productos están manejando el los
elementos de la colección especificación del producto de manera que no
tengo que meter no debo dentro del caso de uso no debo meter en este
catálogo porque es de otro módulo no me no debo meter código específico
para trabajar dentro de este caso de uso de procesar venta porque este
código que metiera en catálogo es de otro módulo y y es para manejar
esta información punto todo lo que tenga que hacerse sí podría ser
inyección de dependencias incluso el la creación del registro podríamos
considerarlo una inyección de dependencias o cómo se llama delegado como
se llama delegación de control me parece si delegación de control podría
considerarse pero olvidaros de eso porque es un mecanismo tan sencillo como
que es este que tiene una jerarquía superior en el funcionamiento y tiene
acceso a los elementos de todos los módulos mantiene la independencia el
acoplamiento bajo simplemente pasándole una copia al controlador lo que os
quiero decir es que vosotros por el hecho de necesitarlo en este caso de
uso de procesar ventas no le podéis meter código métodos para el
tratamiento en este caso de uso a el catálogo métodos al catálogo que es
el que maneja específicamente los elementos de la colección porque los
métodos que se hagan aquí serán ad hoc específicos para el manejo que
haya que hacer en ese caso de uso y no el utilización general de la
colección dentro del catálogo en otro módulo dicho de otra manera que el
catálogo de productos sólo tiene que tener métodos específicos ordenar
obtener un subconjunto en fin para cosas de esas que son específicas de la
información sobre el producto y no las específicas del caso de uso de
procesar venta que ahí eso la los métodos específicos de utilizando unos
objetos u otros que se garantiza que están aislados y que se manejan de
manera aislada esos métodos específicos de lo que haya que hacer en el
caso de uso se implementan en el controlador y se le da al controlador del
caso de uso los los objetos necesarios las copias para que utilicen se
utilicen en la en la construcción del resultado buscado hay otro problema
adicional que es el que os iba a decir que no me va a dar tiempo y es que
aquí no están todos la información de todos los productos que podría
haber en la base de datos no tiene sentido pensar que en esta colección
están pues todos los la información de todos los productos que están hay
una conexión que es para lo que se utiliza ese adaptador que a su vez ese
adaptador que está dentro del negocio el adaptador se conecta con la
fachada que es esta en la parte de acceso a datos en la otra capa y esa
fachada se conecta con la fachada del almacén específico de manera que
una vez que se hace la copia del y ese adaptador es un elemento de acceso
que está en el que maneja toda la colección y está dentro de este este
módulo cuando se hace la copia aquí dentro desde aquí dentro puede
acceder aquí pero es el catálogo el que puede acceder fuera vale pues
hasta la próxima semana para preguntarme las dudas que os hayan surgido
gracias