Hola, en este tutorial voy a afrontar una serie de aspectos importantes
que aunque son de carácter general van a estar enfocados a cómo se maneja
la información y los datos en las distintas partes del desarrollo,
generalizando para la mayor parte de la línea de desarrollo de la
aplicación que estemos fabricando. Bien, recapitulando un poco lo que
llevamos visto y toda la evolución que estamos haciendo del desarrollo, el
ciclo de visión... ...de vida que estamos siguiendo se fundamenta, o uno
de los aspectos en los que se fundamenta, es en el desarrollo basado en
casos de uso. Es decir, en ir haciendo el seguimiento de cómo fabricamos o
elaboramos el software, lo que estamos construyendo, a partir de las
historias de utilización de la aplicación. Bueno, ya hemos visto que en
la parte de inicio hemos intentado identificar cuáles son los casos de
uso, estas historias de utilización de la aplicación para identificar
cuáles son los actores principales que están manejando cada uso.
utilización de la aplicación cuáles son las funcionalidades principales
que tenemos dentro de nuestra aplicación para qué va a servir
básicamente y también identificar qué elementos o sistemas que
consideramos externos bueno, que son realmente externos interaccionan o
requieren cada utilización requieren una interacción con ellos digamos
que es una primera aproximación para situar qué es lo que hace la
aplicación y para qué sirve y cuáles son los elementos funcionales más
importantes que vamos a pasar a desarrollar a continuación a partir de
esta fase de inicio una vez identificados, aunque no sean con total
precisión, cuáles son estos usos de la aplicación esas funcionalidades
principales esos casos de uso que estamos denominando vamos a pasar a
desarrollarlos en paralelo de manera más o menos aislada, es decir, cada
uno de estos casos de uso inicia una línea de desarrollo que es más o
menos independiente lo de independiente fundamentalmente, y es a lo que voy
en este tutorial quiere decir que nos centramos, nos enfocamos
fundamentalmente en ellos, en cada uno para hacer el desarrollo. Con esto
lo que se está buscando es enfocar la atención sobre cada una de las
partes y lo esencial que tiene estas partes sería cada una de estas
funcionalidades. Lo esencial de esa funcionalidad para que ese desarrollo
también vaya centrado en ese aspecto o en estos aspectos esenciales que
tiene cada utilización. Con lo cual se intenta que se gane bastante
precisión, pero a la vez también lo que estamos intentando es conseguir
que cada uno de esos elementos, los casos de uso, consigan esa
independencia que también estamos buscando. Una independencia desde la
raíz. Pero vamos a ver si se entiende lo de esta independencia. El hecho
de que no nos centremos en cada funcionalidad y en implementar
estrictamente esa funcionalidad, al final lo que vamos a construir es un
conjunto de software que va a tener una unidad. Es decir, el software... El
software va a estar todo mezclado. La cuestión es que fijemos nuestra
atención en qué parte estamos desarrollando. Esto también la división
en casos de uso consigue o tiene como objetivo el poder hacer el desarrollo
en paralelo de cada caso de uso. Digamos que es un aspecto sobre cómo se
trabaja, cómo se hace el desarrollo. Pero independientemente de esto, en
el caso de que tengamos, como nosotros estamos aprendiendo, que afrontar
todo, aparte de esta ventaja de poder desarrollar las cosas en paralelo, en
el caso de que tengamos que desarrollar nosotros todo, la cuestión
fundamental en la que me quiero centrar es que es imposible desarrollar
sólo una parte si no se tiene en consideración el todo. ¿Dónde va a
estar funcionando ese caso de uso y cuáles son las interacciones que pueda
haber? Con otros casos de uso y con el funcionamiento general o global de
lo que es la aplicación. Esta idea, que es en la que me quiero centrar en
este tutorial, es fundamental. No se puede enfocar tanto en el desarrollo
de un caso de uso, de manera que dejemos de ver en dónde está funcionando
ese caso de uso, y qué, digamos, interacciones necesarias, porque es que
si no, no funcionaría nada, requiere con el resto del funcionamiento de la
aplicación y correspondientemente el resto del código que está haciendo
todo eso funcionar. Es decir, que al desarrollar, al construir el código
correspondiente a un caso de uso, jamás... ...podemos perder de vista que
hay otro código que lo envuelve... y entre ellos otros casos de uso, o el
código de otros casos de uso, sin el cual sería imposible que eso
funcionara. Independientemente de que lo que estemos construyendo
pertenezca exclusivamente, bueno, exclusivamente, fundamentalmente, a esa
funcionalidad o a ese caso de uso. Bien, a la hora de desarrollar el caso
de uso, cada uno de los casos de uso, pues tendremos que aplicar todas las
fases correspondientes al desarrollo, digamos convencional. Podemos ver
esto como el ciclo de vida en cascada aplicado a un determinado caso de
uso. Es decir, tenemos que hacer un análisis de la funcionalidad, de los
requisitos que tiene este caso de uso y, por último, hacer un diseño que
podría ser detallado y que podría ser arquitectónico y, del detallado,
pues proseguiríamos con la codificación, las pruebas unitarias,
etcétera. Bueno, etcétera. Más o menos hasta ahí podríamos hacer el
desarrollo en esta fase del ciclo de vida que estamos siguiendo, de la fase
de elaboración. Bien, la cuestión es que ya en el mismo análisis, a la
hora de centrar y determinar cuáles son los requisitos, por muy imprecisos
que podamos determinar cuáles son esos requisitos, pues funcionales y de
otro tipo, en este ciclo, en este caso de uso o en un caso de uso concreto,
tendremos que tener en consideración también cuál es el funcionamiento
global conjunto de la aplicación. Cuando pasemos, igualmente, en el
análisis y de esa consideración tanto de los requisitos estrictamente del
caso de uso como de cómo concluimos los requisitos del caso de uso a
partir de condicionamientos del funcionamiento global o conjunto de toda la
aplicación y del caso de uso dentro de ese funcionamiento. De la
aplicación global, todas esas conclusiones van a aportar en el diseño que
también igualmente tendrá que tener en cuenta cómo se implementa eso con
respecto a las implementaciones, cómo se implementa ese funcionamiento que
hemos descrito o que hemos concluido en el análisis. Cómo se implementa
al diseñarlo con relación a cómo se implementa ese funcionamiento
general y cómo afecta ese funcionamiento general también al
funcionamiento, a los requisitos funcionales o la implementación de los
requisitos funcionales estrictamente del caso de uso. De toda la evolución
de la lectura del libro, pues efectivamente se concluye. Se concluye que al
realizar el diseño de lo que es estrictamente los requisitos funcionales
de este caso de uso. Pues ese diseño va a tener que ser un diseño
detallado, pero insisto en que la consideración del funcionamiento global
y cómo con aproximaciones se va a implementar ese funcionamiento global
para que interaccione con este funcionamiento que vamos a definir en el
diseño detallado es que necesariamente tenemos que ir pensando en el
diseño arquitectónico. Es decir, tanto si se tiene mucha experiencia en
la elaboración como si se tiene poca, el desarrollo del diseño detallado
debe ir acompañado y en paralelo más o menos necesariamente, según la
experiencia que tenga cada uno, cada ingeniero, cada desarrollador. Con el
desarrollo del diseño arquitectónico. Es decir, de todo el modelo, de
todo el código que vamos a tener en nuestra aplicación, lo que
corresponde a un caso de uso, al funcionamiento de un caso de uso,
necesariamente tiene que ver con... ...otra serie de, digamos, agrupación
de todo este código en lo que se denominan los módulos o los componentes
arquitectónicos de... La aplicación, en paquetes o en lo que sea, y un
caso de uso en general, la funcionalidad de un caso de uso, es decir, este
código detallado que estamos definiendo, formará parte de distintos
módulos de la distribución en la arquitectura que nosotros iremos
elaborando. Es verdad que, con poca experiencia, esta distribución en
módulos se va relegando hacia el final. Con más experiencia se puede
hacer una vista previa de qué módulos funcionales podían constituir el
funcionamiento general de toda la aplicación y más o menos con esta idea,
con este modelo, todos estos módulos podrían interaccionar entre sí,
evidentemente. Pero cuando estamos desarrollando el código de un caso de
uso, podríamos ir asignando esas partes del código a los módulos de la
arquitectura y viceversa, digamos, por cohesión, por... con criterios de
dar mayor cohesión y unidad a cada uno de estos elementos, por los datos,
por la información que están tratando y su propia funcionalidad,
podríamos hacer esa distribución del código, bien a priori o bien a
posteriori, tomando distintas partes del código que corresponde al diseño
detallado de un caso de uso o de cada caso de uso en concreto e ir
definiendo a qué módulo de la arquitectura podrían pertenecer. En este
caso, con el desarrollo arquitectónico, que digamos que tiene una gran
relación precisamente con el diseño detallado de cada caso de uso o cada
elemento del código que estemos construyendo, pues también habrá que
hacer una codificación porque hay partes de ese funcionamiento a las que
ya me he referido muchas veces, como son la parte del gobierno de la
aplicación que maneja cuáles... ¿Cuál es el flujo de trabajo global de
la aplicación? Es decir, pues son todas las partes y más, pero las que
dan arbitran cuando entra cada uno de los casos de uso. La distribución,
el flujo de trabajo general, cuando entra un caso de uso, cuando se pasa a
otro caso de uso, etc. Eso también va a requerir una codificación y unas
pruebas de integración correspondiente a la integración de todos los
módulos y cómo se comportan las interacciones que hay entre los módulos,
independientemente de cómo se comporta dentro de un caso de uso o de la
utilización específica de un caso de uso, de la aplicación dentro de un
caso de uso. Bien, por otro lado, en este desarrollo de cada caso de uso,
además de tener en cuenta el funcionamiento global, hay que tener
simultáneamente la vista puesta en cuál es el funcionamiento o cuál
queremos que sea el funcionamiento de nuestro caso de uso. Es decir, de la
utilización de la aplicación en esa historia de utilización de uso,
cómo funciona globalmente, en general, para este caso de uso y los demás
de la aplicación. Vale, pues además de esa simultaneidad de enfoque en lo
concreto del caso de uso y en lo global de toda la aplicación. El
desarrollo de los casos de uso también se va a hacer centrado en la capa
de la lógica del negocio. Esta imagen ya ha salido varias veces. digamos
que todo el código está dentro de esta caja, otra de las cosas que se van
a hacer desde el principio y también para conseguir esa independencia, esa
individualización de lo que estamos construyendo en función de a qué se
dedica o para qué se utiliza precisamente ese código que queremos
construir. Es separar todo el código en distintas capas, en distintas
categorías. En distintas capas, insisto, en función de cuál es el
ámbito o el entorno de funcionamiento y su objetivo de funcionamiento de
ese código que vamos separando. El horizonte es precisamente discriminar y
separar, hacer una cirugía. Para decantar estrictamente para qué sirve
cada parte del código. Para cualquier cosa, separaremos la parte
correspondiente que da servicio a la capa de presentación, como por
ejemplo la interfaz de usuario, la que da servicio a los servicios
técnicos, como puede ser el acceso a los datos, como pueden ser los
distintos sistemas externos de apoyo que vamos a necesitar, y centrarnos
precisamente en esta capa de la lógica de negocio, que es lo que hace las
funciones esenciales, o lo esencial de esas funciones que nosotros estamos
buscando. Estamos intentando discriminar todo lo que no sea lo que vayamos
a trabajar. Evidentemente, la parte de la interfaz de usuario, para que...
Se acepten los datos en nuestra lógica de negocio y en el código que da
servicio a la funcionalidad, por ejemplo, de cualquiera de los casos de
uso, pues eso también tendremos que implementarlo. Igualmente, si lo que
tenemos aquí es, por ejemplo, una base de datos y estamos recogiendo la
información de esa base de datos, pues evidentemente lo que da servicio a
esa obtención de la información en la base de datos son servicios
técnicos de bajo nivel que estarán... Será código que también
tendremos que implementar y que estarán situados precisamente en esta capa
de servicios técnicos. Digamos que esto no es lo esencial de la
utilización o del caso de uso que queremos implementar. Volvemos a ver la
maniobra de centrarnos estrictamente en lo que estamos elaborando. Todo
esto se organiza, que es de cada cual y cómo se accede y cómo se utiliza
lo de fuera o la parte que corresponde a estos servicios técnicos o la
entrada y salida de los datos en la capa de presentación. Todo eso lo
organiza lo que hemos denominado la capa de la lógica de la aplicación y
del gobierno de la aplicación. Es decir, que todo es código que tendremos
que desarrollar y las interacciones del actor que maneje la aplicación o
un caso de uso irán por la capa de presentación a nuestro caso de uso que
estará aquí dentro. El caso de uso en realidad o el código será todo,
pero lo que nosotros estamos centrando nuestra atención es en este código
correspondiente a este caso de uso. Bien, pues las interacciones irán a
través de la capa de presentación manejada por la capa de la lógica de
gobierno, la capa de presentación a nuestro caso de uso y de igual manera,
pues todos los servicios o datos que requiramos del exterior a través de
la gestión de la capa del gobierno, de la aplicación, también serán
utilizables con distintas adaptaciones, serán utilizables dentro de lo que
nosotros estamos. Estamos implementando. Esta es una visión que es
fundamental e insisto, no sólo estamos viendo para construir el código
que hay, que corresponde a este caso de uso, no sólo tenemos que ubicarlo
aquí dentro en la capa de negocio para quitarnos de despistes y de cosas
que no tienen estrictamente que ver con la... esencia de la funcionalidad
que estamos elaborando, sino que tenemos que ver o tener presente que aquí
hay también un trabajo que no estaremos implementando ahora mismo porque
no es de este caso de uso, pero que sin este código y sin esta forma de
funcionamiento... Es imposible que nosotros podamos construir esto, así
que lo de caso de uso. Así que necesariamente hay que tenerlo en cuenta
cuando lo elaboremos en ese desarrollo paralelo de cada caso de uso. Bien,
voy a terminar enfocando el tratamiento o la perspectiva con la que hay que
manejar la información que estamos manejando dentro del caso de uso,
según la procedencia de esa información. Según su significado dentro del
funcionamiento del caso de uso. Por un lado, podríamos categorizar según
esto, aunque esto para nada es canónico, que hay determinados datos o
información que están compartidos o mantenidos o utilizados en distintas
operaciones, en distintos casos. En distintos casos de uso o en distintos
módulos de la arquitectura. Por ejemplo, serían las características de
los productos en venta que tenemos dentro del caso de uso de ventas en el
ejemplo del libro de punto de venta. Lo que llama especificación del
producto, por ejemplo. En el ejemplo que sigue el libro, en realidad,
sería precios de productos. Esa característica es la de precios de
producto. La característica principal sería el precio, por tanto. Bien,
este, llamémoslo así, aunque en el análisis pueda ser un objeto
conceptual, no es código, pero incluso después en el código, esto, el
precio de los productos que hay en venta, pues, en principio, además,
tiene una naturaleza de que tenemos una colección de ellos, es un
multiobjeto, pero la característica principal es el precio y ese precio se
puede estar utilizando, o la cuestión es que en el razonamiento de cuál
es el funcionamiento global, esta información o estos datos, como lo
queremos llamar en cada momento, estos datos se van a estar utilizando,
pues, tanto en ventas como en el módulo de mantenimiento de... productos o
el de inventario que llaman más adelante, o en precios, un módulo de
política de precios, pues podrían estarlo manejando o podría ser
necesario. Es decir, estos datos es lógico y por eso estas reflexiones hay
que hacerlas en el análisis, es lógico pensar, aunque estemos
desarrollando el caso de uso de procesar una venta, es lógico pensar que
esta característica en concreto, que no son todas las características que
pueda tener el producto, pero esta en concreto también, o todas también,
forman parte del funcionamiento de distintos otros casos de uso e incluso
el código forma parte de distintos paquetes en los que vamos a organizar
luego la arquitectura de toda nuestra aplicación, independientemente de la
parte de interfaz de usuario y del acceso a los datos. ¿De acuerdo? Estoy
hablando desde un punto de vista lógico superando esa distinción en las
tres capas. La cuestión es que los precios del producto o las
características del producto en sí es uno de estos tipos de información
que vamos a estar manejando en distintos sitios, en distintos casos de uso.
Esa consideración resulta bastante importante a la hora de determinar en
el funcionamiento del caso de uso qué podemos hacer con ese tipo de datos,
qué es conveniente hacer y qué no es conveniente hacer. Por ejemplo, en
el caso de uso de procesar venta no se requiere cambiar el precio de un
producto ni ninguna de sus características, no es esa su función. De
manera que todo lo que se refiere al precio del producto no deberíamos
considerar. Ni elementos de información como atributos que no sean
correspondientes estrictamente a lo que es la característica del producto,
cosas derivadas, etc. Ni deberíamos pensar, quiero decir que debería
estar hasta cierto punto prohibido pensar en... ...alguna funcionalidad,
algún método, o sea pensar en añadir algún método, alguna
funcionalidad a los objetos que están manejando esa característica porque
están afectando al funcionamiento de los otros sitios donde se está
utilizando este tipo de información o este objeto. Esto es fundamental
para conseguir esa independencia funcional y, por supuesto, esa
flexibilidad que estamos buscando en nuestra aplicación. Ya vengo diciendo
respecto a la separación en casos de uso, la separación en capas respecto
al razonamiento que se tiene, debería centrar en eso, y todo precisamente
es para conseguir ir entreverando en todo lo que hagamos ese objetivo de
separación, de independencia en lo que estamos manejando. Bien, pues esto
es especialmente importante en este tipo de datos compartidos. Hay otro
tipo, otra categoría que podríamos pensar es en información, son datos,
servicios obtenidos de sistemas de apoyo externo. Un ejemplo de esto
podría ser la autorización del pago con tarjeta en PDV. Son datos,
valores obtenidos de sistemas de apoyo externo que en sí no tienen, porque
formar parte de datos, en principio, de datos de este otro tipo, datos
compartidos, aunque el devenir del funcionamiento del caso de uso... Ese
dato obtenido a partir de un sistema de apoyo externo o enviado a un
sistema de apoyo externo, los que provienen de un sistema de apoyo externo
podrían formar parte de esos datos que se están compartiendo. Pero sin
más, para hacer esta categorización de los distintos datos o información
según la procedencia, en principio una vez que lo tengamos dentro de
nuestro caso de uso, dentro de nuestra área de negocio, pues no
importaría hacer una modificación en estos datos porque no tendríamos
que estar... No tendríamos que estar pendientes de lo que hagan los
demás. Si forman parte de datos compartidos o si pasan a compartirse con
otros elementos, a partir de ese momento efectivamente tendremos que tener
las consideraciones que acabo de decir para los datos compartidos. Otro
tipo de datos serían los obtenidos por parte del actor. Como por ejemplo
la cantidad... La cantidad del artículo que está comprando el actor en el
caso de uso de procesar venta en PDV. O bien la identificación, esto puede
ser el ID o podría ser una cadena, da lo mismo. Pues la cantidad y el
artículo que está comprando el actor sería un ejemplo de los datos
obtenidos por el actor. Efectivamente, con esto también podremos hacer lo
que queramos en tanto en cuanto no sean datos que están compartidos en
otras partes del caso de uso. Perdón, otras partes de nuestra aplicación.
Y por último habría otros datos, otra información elaborada ad hoc en el
caso de uso. Pues pueden provenir estos, digamos si lo vemos desde el punto
de vista de los objetos conceptuales, pues pueden provenir tanto de la
información que obtenemos de datos compartidos como de la información que
obtenemos... Veremos de datos obtenidos de los sistemas de apoyo como de la
información obtenida del actor que maneja el caso de uso. Pues a partir de
ellos podemos construir otro tipo de datos, otro conjunto de información y
esa puede pasar a formar parte de los datos que son compartidos o enviarlos
a un sistema de apoyo externo o como resultado de lo que está buscando el
actor, etc. Vale, pues con estos... Cuatro tipos de datos es con lo que nos
estamos, o cada uno de ellos debería tener su consideración propia o
separada, tanto a la hora de crear la lógica, el concepto de cómo
funciona o cómo tiene que funcionar el caso de uso en el modelo de
dominio, así como luego cuando se implemente en un diseño detallado esa
lógica de funcionamiento. Deberíamos... Debemos, o deberíamos, tratar de
una manera diferente cada uno de estos cuatro tipos de datos o de
información que, bueno, pues me he inventado yo, según su procedencia.
Cada uno de ellos debe considerarse de una manera diferenciada. Bien. Es
muy frecuente... Antes de pasar a otra cosa. Es muy frecuente que estos
datos compartidos, de estos también podría ser, formen parte o requieran
una gestión de su persistencia. el que una información esté compartida
entre distintos módulos es distinto a que esta esa información o un dato
requiera que requiera ser persistente es decir, que se maneje con
persistencia quiere decir que aparte de lo que se está haciendo con ella
necesita que mantenerlo de una manera estable y persistente su propio
nombre lo indica a pesar de lo que se esté haciendo que la aplicación se
finalice, que se haya terminado el caso de uso que se pase a otro caso de
uso etcétera eso significa que requiera persistencia uno de los elementos
el caso más claro es el almacén en un lugar o de una determinada forma
que permanezca normalmente los datos compartidos que se manejan entre
distintos o es muy frecuente al menos los datos que se manejan entre
distintos módulos y entre distintos casos de uso además requieran
persistencia insisto que cualquiera de estos otros tipos de datos pues
pueden formar parte de datos que van a ser compartidos y además podrían
formar parte del sistema de persistencia, es decir, requerir que se
guardaran de una determinada manera. El requerir que se guarden de una
determinada manera pasa, o ese comportamiento pasa no sólo por definirlo
en la lógica del modelo de dominio, en la lógica del funcionamiento, sino
luego a implementarlo, y hay que implementarlo de una manera específica.
Una manera específica que además debe garantizar esa independencia de
cómo se gestione la persistencia, la independencia del funcionamiento, del
caso de uso y de todo el código de la capa de negocio que sea
independiente de cómo se gestione la persistencia. De el código
correspondiente a la persistencia de los datos que estamos manejando. Cada,
el código debe encargarse de un funcionamiento muy concreto y ser ese
funcionamiento de ese código independiente del funcionamiento de otro
código. Eso es lo que estamos intentando, estamos buscando, intentando
conseguir con lo de la independencia funcional, para conseguir esa
flexibilidad que estamos buscando en nuestra, en nuestro desarrollo, en
nuestra aplicación. Como ejemplo finalizo con los distintos tipos de
información y de datos, que aparecen en el modelo de dominio del caso de
uso de procesar una venta, en el ejemplo del libro. En el caso de los datos
asignados o que provienen del actor que maneja el caso de uso, básicamente
en este ejemplo que está recogiendo el encargado sería el que está
realizando la inicialización del caso de uso antes de empezar a admitir
ventas, el cliente tiene como intermediario al cajero y es el cajero el
que... básicamente está interaccionando con el caso de uso. Así que el
que inicia la venta sería el cajero y es el que está registrando esas
ventas. En fin, esta relación en principio no es muy relevante. Es verdad
que el cliente sí que sería el que realizaría... El pago, por ejemplo,
si lo hace con una venta en tienda, entendámonos. Está realizando el
pago, bueno, pues en el caso del que es el que está considerando
inicialmente, en el caso de pago en metálico, sí que aportaría la
cantidad. Bien. Quiero decir que esta cantidad sería la correspondiente a
la que aporta el cliente al hacer el pago en metálico. Es de tipo dinero
para aislarlo. Otro de los elementos que daría el cliente o el cajero,
vamos, el actor que está manejando el caso de uso es esta cantidad. Otra
de las cosas que quiero llamar la atención es que como en una línea de
venta o un ítem de venta que se está, que está comprando el cliente o
está vendiendo el cajero viene descrita por esta especificación. Veo así
que se pone la cardinalidad en todos. Esta especificación, esta
descripción, es decir, este precio no se pone como atributo puesto que ya
está referenciado y definido en el ítem vendido. No, está referenciado y
definido en la descripción de ese producto actual. A partir de esta
relación. De la misma manera, la tienda no tiene el elemento registro
venta. Registro venta no tiene el conjunto. así como atributo, no tiene
listas, o sea, ventas list, por ejemplo, si lo quisiéramos llamar así.
No, no, ya está definido con esta relación que el componente venta forma
parte de registro de ventas. Igual que aquí no tiene ítems, el listado de
ítems, porque está referenciado mediante esta relación. De manera que no
se vuelven a repetir esas cosas que cantidad, insisto, es algo que viene a
través de la interfaz de usuario y del componente. El controlador viene
como característica que aporta el actor en el ítem vendido. Así que
resulta que esto sí son datos que se están compartiendo en distintos
módulos del de la aplicación o en distintos casos de uso. Pues, por
ejemplo, para mantener el inventario o, en fin, las especificaciones o las
características del producto se utilizan en distintas partes del De la
aplicación y en distintos casos de uso. Este tienda que aparece ahí es el
controlador del gobierno de la aplicación. El que en algunos ejemplos yo
denomino nivel sería el controlador jerárquicamente por encima del
controlador del caso de uso. Que es registro venta o registro como lo llama
en el libro. Así que todo esto forma parte o hay que tener una
consideración muy especial en cuanto a qué hacemos con esto. Y el
catálogo que está conteniendo es el contenedor del multiobjeto de la
colección. De precios de los productos. Qué es lo que podemos hacer con
esto dentro de un caso de uso. Hay que tener mucho cuidado con cuáles son
las operaciones o las funcionalidades que asignamos. Las responsabilidades
de operación que asignamos a estos objetos. Cantidad pues por mucho que
sea bueno esto puede ser un número. Pero esta cantidad debe ser. Dinero
por mucho que no sea un tipo primitivo de datos pues son. información que
está aportando el actor principal y no es necesario tener muchas
consideraciones respecto a qué podemos hacer con ello. Podemos hacer casi
lo que queramos. En este ejemplo no veo ahora datos que provengan de
sistemas de apoyo externo. Bueno, en el caso de que necesitáramos una
autorización del pago pues sí provendrían algún objeto, alguna
información que podríamos asignar a un objeto conceptual y en ese caso
este provendría de un sistema de apoyo externo. Pero en principio aquí no
se ve. Otro tipo de datos que sí se puede identificar aquí es lo que se
va elaborando como objetivo del actor principal y ese es el resultado que
espera es todos los datos correspondientes a la venta que incluyen los
ítems, cada uno de los ítems y la información de ellos como su precio
sobre todo y cuánto está comprando de ese tipo de ítem. Pues este dato
se va elaborando ad hoc dentro del caso de uso. constituye precisamente el
objetivo o el resultado buscado por el actor del caso de uso, el actor
principal que maneja el caso de uso. Además, venta y todos los ítems
vendidos con la información correspondiente va a formar parte de
información de tipo persistente y que se va a utilizar en otros ámbitos,
en otros casos de uso y en otros módulos de la aplicación, aunque se
esté elaborando. Y no hay ningún problema en ello, aquí se elabora tal
cual y se va construyendo este elemento. Pero después, esta venta, una vez
pagado, se va a pasar a contabilizar y esta venta se va a pasar a control
del inventario para actualizar el stock que estuviera registrado. Y, en
fin, que tanto va a tener un carácter y en contabilidad a la venta le
darán un identificador, que en realidad ese tipo de identificador si es de
tipo que es de naturaleza persistente. Se lo darán en contabilidad o se lo
darán en otra parte, pero el caso es que va a formar parte de posiblemente
un multiobjeto de las ventas que va a estar contenido en un catálogo de
todas las ventas que tendrán una asociación con los recibos producidos,
etcétera, etcétera. Es decir, que según sean estos datos o esta
información que estamos manejando, aunque sea a nivel conceptual, hay que
tenerlos en consideraciones bien distintas y también, a la vez, no sólo
para lo que se... o sea, hay que tenerlo en consideraciones bien distintas
para lo que se puede hacer con ellos y, a la vez, tener... en
consideración que todo esto viene de el gobierno de la aplicación. Es el
gobierno de la aplicación el que da acceso y tiene presente estos tipos de
datos o esta información que se está compartiendo entre distintos sitios
y, a su vez, el controlador del caso de uso. Y cuando se termine la venta,
a través del registro, quedará registrado dentro del controlador y
pasará, como he dicho antes, a formar parte de los datos que se comparten
entre distintos casos de uso o entre distintos módulos. E incluso que
requiera una persistencia, es decir, que se almacenen de manera persistente
en algún sitio. Pues con esto termino este tutorial sobre la distinta
consideración que hay que tener con datos que aunque sean todos
agrupaciones o información de distinta naturaleza, según donde provengan
y donde se estén utilizando y para qué, hay que tratarlos de distinta
manera. Y hay que considerarlo tanto... A la hora de concebir la lógica
del funcionamiento, es decir, en el diseño de la lógica del
funcionamiento requerido o que estamos concibiendo en el modelo de dominio,
como luego en el diseño detallado al implementarlo con código. Pues nada
más.