Comenzamos esta primera tutoría de la asignatura en el curso para el 2024
y voy a empezar compartiendo. Vale, ¿se ve bien? Vamos, es una página en
blanco. Sí, sí, se ve la página en blanco. Estupendo. Bueno, antes que
nada no sé si tiene alguna pregunta porque tenía intención de hacer un
repaso a buena parte de la asignatura pero no sé si tiene alguna cuestión
que quiera tratar antes o verlo. He estado leyendo un enunciado del PUF,
del proyecto original, y las tres primeras preguntas son las mismas que las
de APEC, o ir a combatir… Ha cambiado un poquito la redacción en algunos
aspectos. En las conversaciones en los foros me había parecido que podía
llevar algún malentendido y entonces he cambiado la redacción en algunas
cosas, tanto del escenario general sobre la definición del caso de uso y
respecto a algunas explicaciones sobre las simplificaciones. Lo he puesto
en los foros, no sé si lo ha visto una explicación sobre esas
modificaciones que podía haber habido. El esquema es, aparte de estas
pequeñas modificaciones que sustancialmente ni cambian el escenario ni el
caso de uso sobre el cual se trabaja durante todo el trabajo, la cuestión
es que en la prueba de evaluación continua, que no tienen por qué hacer
todos los estudiantes, se preguntan una serie de cosas y esas mismas cosas
que se preguntan en esas tres preguntas son las que se preguntan en el
trabajo global correspondiente a la convocatoria de febrero. De manera que
el hacer las tres preguntas en la prueba continua no exime de hacer esas
mismas tres preguntas y poner las respuestas en el trabajo final. ¿De
acuerdo? La idea es que en el ejercicio de la prueba continua, de
evaluación continua, se enfrente tanto al escenario como ya a modelar,
hacer el modelo conceptual de la lógica del funcionamiento del caso de uso
y con la realimentación que pueda obtener de su tutor más la
realimentación que ya estoy dando en los foros al responder a las
cuestiones que se me plantean, pues con eso se rehaga o se pueda mejorar el
trabajo final. Esas mismas tres preguntas del trabajo final y las otras, no
sé, las que sean, parece que son seis, las otras seis preguntas de la
prueba final, digamos del trabajo final. De manera que se mejore porque la
calificación, la evaluación fundamental viene de ese trabajo. Ese trabajo
no lo valoran los tutores como el de la evaluación continua sino lo
evaluamos los profesores del equipo docente. ¿De acuerdo? Sí, sí. Me
consta que es así. Vale. De acuerdo. Muy bien. Pues no sé si hay alguna
pregunta o algún participante que se acabe de incorporar. La cuestión,
una cosa que me parece importante y que no pensaba en el recorrido que
pensaba hacer de lo que es los elementos fundamentales de la asignatura era
decir que siguiendo estrictamente lo que aparece, los contenidos que
aparecen en el libro por la experiencia que hay de todos estos años no es
suficiente para comprender o enfocar cuáles son los objetivos
fundamentales de esta asignatura. El libro desde luego trata bastante bien,
porque está muy reconocido ese texto en muchos ámbitos especialmente en
el universitario. Se trata evidentemente sobre el diseño. El diseño, para
ponernos todos de acuerdo, es la definición del comportamiento o del
funcionamiento de algo que le permite conseguir el propósito por el cual
ha sido concebido, ha sido creado. Es decir, todos esos mecanismos de
funcionamiento gracias a los cuales cualquier cosa, aunque sea un
procedimiento o en fin lo que sea y más específicamente software que
escribimos. Todos esos mecanismos son los con los que si el software tiene
como propósito obtener un determinado resultado, pues el diseño es la
definición de cómo obtiene ese resultado. En fin, lo que acabo de decir.
Cómo se alcanza ese propósito por el cual fue concebido. El crear
software que responda a unos determinados requisitos funcionales, eso se ha
aprendido en todas las asignaturas correspondientes a algoritmia, a
programación, etcétera. De manera que más o menos eso se supone sabido.
Así que ese escalón en el diseño, otra cosa sería cómo expresarlo.
Estamos utilizando aquí UML pero no es el objetivo enseñar UML en esta
asignatura. Y entonces podría haber alguna dificultad en cómo expresar
precisamente esos funcionamientos o esos mecanismos de comportamiento para
alcanzar esas metas, esos objetivos. La cuestión es que a raíz de lo que
aparece en el libro de los contenidos, efectivamente está ahí mostrando
cómo se diseña utilizando un ejemplo vehicular para mostrar esa forma de
hacer diseño. Pero el estudiante simplemente leyendo ese libro podría
imaginarse esas formas de hacerlo y otras muchas que también son diseño y
también responden al cumplimiento de los requisitos funcionales que se
plantean precisamente en el libro. La cuestión es que en esta asignatura
vamos a o se intenta enseñar o que el estudiante aprenda el cómo
conseguir un diseño de calidad, un buen diseño. Todo esto que estamos
estudiando y todo lo que se plantea es que de esa manera se consigue ese
buen diseño. Y las características de ese buen diseño son la
flexibilidad, es decir, la adaptabilidad de ese funcionamiento ante
pequeñas variaciones, la independencia funcional y la sencillez, la
comprensibilidad. Esta definición de cómo funciona pues sea fácilmente
entendible para poderlo modificar también con facilidad. Es decir, que
todos estos elementos cualitativos de calidad de cómo tiene que ser un
diseño van orientados precisamente al mantenimiento, a la expansión,
incluso al coste, a un enfoque más ingenieril de lo que es el desarrollo
del software. Algo que nos va a permitir hacerlo y con modificaciones
adaptarlo a otras situaciones ligeramente diferentes o que no sirvan para
una familia de aplicaciones, una familia o un poco más corta, un abanico
un poco más corto, etcétera. Entonces, dejado sentado que la revisión
autónoma individual del estudiante de lo que es el contenido del libro
creo que no es suficiente para comprender bien cuáles son los objetivos de
la asignatura. Y para, digamos, seguir esos contenidos y obtener el
aprendizaje deseado y por lo tanto el evaluado la recomendación es que se
compagine todo eso con las referencias. Aunque, bueno, tengan también sus
defectos porque uno es humano y tampoco... En fin, reconozco los defectos
que pueda tener pues con el material escrito que hay en el curso virtual,
las explicaciones que puedo dar en los foros en el curso virtual, los
videotutoriales, los manuales escritos, etcétera. Es decir, que en la
medida de lo posible se intente compaginar esos materiales que acabo de
decir con la lectura porque la lectura exclusiva del libro no es
suficiente. Igual que tampoco lo son pues los videotutoriales si uno se ve
sólo los videotutoriales pues tampoco se va a enterar de qué va lo que
estamos intentando hacer. Y todo eso se aplica evidentemente a las
evaluaciones tanto a la orientación de cómo deben ir las respuestas en la
evaluación continua como la orientación de cómo tienen que ir las
respuestas en el trabajo final. ¿De acuerdo? ¿Está esto entendido? No
sé si hay más participantes... Se me ha ido la pantalla esa. Bien,
entonces dejando bien claro qué es diseño y qué tipo de diseño busca o
el aprendizaje de qué tipo de diseño busca los objetivos de esta
asignatura. Digamos que voy a ir acompañando también a lo que es las
preguntas de las pruebas de evaluación paso por paso. En la primera fase
vamos a seguir un proceso unificado que no es más que un ciclo de vida
iterativo. No tiene mayor trascendencia en tanto en cuanto... Bueno, la
tienen cierta medida. ¿En qué consiste ese ciclo de vida? Pues se ha
visto en la asignatura de Introducción a la Ingeniería de Software. La
cuestión es que en esa asignatura sobre todo el estudiante ha tenido
experiencia, sobre todo se ha ejercitado en el desarrollo en cascada y
está acostumbrado a cada fase que ataca, digamos, revisarla y terminarla
como un capítulo adicional. Que no se vuelve. Esto, digamos, evidentemente
se contrapone a los ciclos de vida incrementales e iterativos, a las
metodologías ágiles, etcétera, etcétera. Aquí estamos más cercanos a
esa forma de trabajar que es, digamos, más actual. Pero una de las
barreras sería romper esa resistencia a dejarlo todo absolutamente
resuelto. En la fase de inicio, en la primera fase del proceso unificado,
pues es una visión general, es un repaso, un inicio de la planificación
del desarrollo. Es decir, es una primera aproximación a todo el desarrollo
que vamos a realizar después del cual se separará una rama y en esa rama
es la única en la que nos vamos a centrar. Pero eso no quiere decir que
existan las otras y me refiero a lo que se denominan los casos de uso y el
desarrollo por casos de uso. Bien, una de las actividades que se hacen en
esa fase de inicio como un artefacto, un activo que se obtiene de esa fase
sería el diagrama de casos de uso. Entroncándolo en esa visión general
del proyecto o del desarrollo que estaba mencionando. En este diagrama,
fundamentalmente, aparte de otras cosas que hay que hacer como esa visión
general, ese inicio de la planificación, ir organizando los recursos del
desarrollo que sean necesarios, esa planificación, decir en qué es lo
primero que vamos a cometer, etc. Una de las cosas que se hacen es
precisamente este diagrama de casos de uso donde el objetivo principal es
determinar cuál es la funcionalidad. Como estamos en el principio, en el
inicio, cuál es la funcionalidad fundamental, lo que yo denomino primaria
de la parte del software, de la aplicación, sea grande o sea pequeña, de
lo que vamos a construir. Eso es lo que se denomina los casos de uso. Los
casos de uso se identifican dentro de los márgenes de lo que es el
software que vamos a construir y quiero llamar la atención sobre también
determinadas cosas que estoy viendo o leyendo entre los alumnos. Estamos
hablando siempre de software, es decir, de lo que al final va a ser código
y de su comportamiento. Ese software no va a hacer cosas en el mundo real,
en la física. Así que hay que tener cuidado incluso cuando modelemos ese
modelado conceptual del que he hablado anteriormente y atribuyamos al
software, que es lo que estamos modelando y su funcionalidad, su
funcionamiento. Atribuyamos al software cosas que no hace el software, que
lo hacen pues el hardware o los actores humanos, otro tipo de actores,
otros sistemas que pueden ser software pero no están dentro y por eso es
importante delimitar esto es lo que voy a hacer y esto que hay aquí fuera
no es lo que voy a hacer. Y puede ser software, puede ser hardware, puede
ser lo que sea pero yo pongo este límite y dentro de este límite estoy
identificando esas funcionalidades que es lo que denomino casos de uso. Un
caso de uso es una utilización completa del sistema software del que
estamos hablando que produce un resultado, puede ser tangible o puede no
serlo pero produce un resultado final y eso sería un caso de uso.
Fundamentalmente un caso de uso primario o lo que llama el libro también
un EBP, Elementary Business Process. Estamos en el inicio y de lo que se
trata es de identificar esos casos de uso primarios o principales. Es muy
típico posiblemente porque aquí en el libro aparece un caso de uso que
sería gestionar la seguridad pues que el estudiante diga ah bueno pues la
identificación o la autentificación al acceder a la aplicación es otro
caso de uso. Hay que entender que nadie se accede al sistema para
identificarse y para digamos corroborar las credenciales de identificación
en el acceso. No tiene un resultado final concreto simplemente ha entrado
en la aplicación eso no puede ser nunca un caso de uso. La
autentificación o la autentificación segura eso no es. Ahora el gestionar
la seguridad significa otra cosa digamos parametrizar el funcionamiento de
una aplicación para que garantice precisamente que el acceso sea seguro y
que no haya una intervención. Con mala intención por parte de otra
persona o de otro actor. Entonces gestionar la seguridad significa una cosa
muy diferente y sí que puede ser un caso de uso primario a realizar el
acceso o autentificar el acceso de un actor. Una vez resuelto o por lo
menos lo he intentado este malentendido frecuente las otras cosas es qué
actores principales o qué actor principal maneja precisamente cada uno de
los casos de uso. Es evidente que no veo con buenos ojos ni puedo concebir
un caso de uso que sea principal que no esté manejado por ningún actor.
Es algo que no se ve un caso de uso principal al menos tiene que estar
manejado por algún actor. Otra de las cuestiones que se ponen en este
diagrama es un determinado caso de uso con que otros actores de apoyo sean
humanos o sean sistemas software o sean sistemas hardware o sea lo que sea
pero que son de apoyo y no pertenecen por lo tanto a los límites del
software que vamos a construir. Con cuáles interactúa o requiere
interacción. Por ejemplo tales como se ha planteado los requisitos o el
planteamiento de procesar venta pues procesar venta tiene que interactuar
con el sistema de contabilidad porque se ha decidido que los sistemas de la
contabilidad o la gestión de la contabilidad facturación etcétera. Hay
diversos paquetes que pueden ser de distintas prestaciones y no lo vamos a
incorporar dentro del software que nosotros vamos a realizar. Por lo tanto
esa responsabilidad va a recaer sobre un paquete externo en lo que nosotros
vamos a hacer y para procesar una venta tendrá que interactuar con el
sistema este de contabilidad que será otro software que le dará algún
servicio o intercambiará información con lo que está manejando
precisamente el caso de uso de procesar venta. Lo primero entender para
qué es este diagrama. En segundo lugar entender que establece unos
límites de lo que vamos a construir. En tercer lugar identificar cuáles
son o cuáles son los actores principales que van a manejar cada caso de
uso. Y en tercer lugar identificar los actores de apoyos secundarios con
los que va a interactuar cada caso de uso o alguno puede no interactuar o
necesitar interactuar con ningún elemento externo. Ahora matizaciones.
Estamos en el inicio entonces perfilar en cuántos subfunciones o casos de
uso de digamos menor relevancia no primarios se compone uno determinado un
caso de uso primario se puede hacer pero en el inicio pues tampoco tiene
demasiado sentido no es recomendable o yo por lo menos no lo recomiendo en
este diagrama y en esta parte del desarrollo en la que estamos diferenciar
o pormenorizar el contenido de subfunciones de casos de uso primarios. Hay
salvedades en pues por ejemplo en la evaluación pero ya hablaré con ellas
y de la misma manera tampoco recomiendo pormenorizar los tipos de usuarios
principales o los perfiles distintos de uso que pueden tener con la
aplicación en este punto del inicio del desarrollo. Me parece que no
aportan ninguna o pocas ventanas, ventajas sustanciales. Y por otro lado el
poner demasiados actores o perfiles de uso como manejadores de estos casos
de uso primarios pues establece complica las líneas de interacción.
Entonces creo que dificultan la lectura y la comprensión de cuál es la
funcionalidad esencial que lo que estamos buscando en este día en este
diagrama. Respecto a lo que decía ese matiz de la pormenorización de los
casos de uso de subfunción por ejemplo o derivados o los include, los
extend, etc. Pues efectivamente en la evaluación hay veces que se pone un
caso de uso que hombre primario, primario no parece es más bien
chiquitito. Eso de que sea chiquitito es precisamente para simplificarlo
para que el desarrollo no tenga que ser monumental en lo que haya que hacer
en el trabajo. Entonces es una función más bien pequeña que
efectivamente puede derivar de un caso de uso más general que aglutina a
todos ellos. Por ejemplo hay un caso de uso típico que sería la gestión
de elementos dentro del manejo de elementos de información que forman
parte de una colección. Lo que estamos denominando la gestión cruz. A ver
si atino con esto para escribir. Esto significa, estas son las siglas de
create, retrieve, update y delete. O sea quiere decir crear, eliminar,
modificar, recuperar un elemento de información que forma parte de una
colección. Es un caso muy típico en donde esto son cuatro casos de uso
diferenciados pero los aglutinamos en una gestión cruz de algo. Hay veces
que lo que se está pidiendo, el caso de uso que se está pidiendo
precisamente es un alta de un elemento de una determinada colección.
Crear. En ese caso pues sí que viene bien en este diagrama que se está
pidiendo ahí poner crear o alta de lo que sea. Alta presa. Como partícipe
de esta gestión cruz de las presas o de los elementos hídricos que
estamos manejando en este escenario. Si no pues yo la verdad mientras se
pueda evitar todo ese desglose en subfunciones y en casos de uso derivados
pues mejor. Ojo a lo que he dicho con respecto a que tiene que haber una
línea de al menos un actor que maneje y digamos también los actores de
apoyo que se puedan poner. De acuerdo. ¿Alguna pregunta sobre esto?
Básicamente el número de actores que pueda haber en un sistema. ¿El
número de? El número de actores principales que pueda haber variará de
un sistema a otro. Porque por ejemplo creo que en la PEC digamos que más
bien había uno porque bueno había un usuario así genérico. En la PEC.
Sí, sí. Yo lo que acabo de decir es la recomendación sobre los actores
es que en esta parte del desarrollo prefiero en lugar de lo que aparece en
el libro cajero, cliente, encargado, administrador utilizar un usuario
único Un usuario único sin distinguir todos estos perfiles que manejan
todos. No es que uno tenga más que otros, eso no es así. Hombre, claro
que es así efectivamente. O sea que hay aplicaciones y en la PEC y en el
PUF en los trabajos de este año he puesto un usuario único pero debería
ser un encargado el que realizara las operaciones que estoy diciendo A
diferencia pues por ejemplo de cualquier otro usuario que posiblemente la
maniobra esa de carga de un buque en lo que consiste el caso de uso de este
trabajo no lo puede hacer yo qué sé, un operario de cubierta del buque.
Tiene que tener una determinada autorización porque tiene unas
responsabilidades bastante fuertes. De hecho, si se ve cuáles son los
procedimientos de carga en este sentido hay varios actores humanos. Cada
uno con unas responsabilidades muy definidas que intervienen en todo este
proceso. Una cosa es para simplificar, vamos a poner un usuario así
genérico y en este caso No sé si me va a pintar. En este caso es que
resulta que el libro dice vamos a tener una caja y esa caja va a ser el
encargado el que abre sesión o abre la caja, digamos en esa
inicialización Y resulta que es el cajero el que abre sesión seguramente
en su cuenta y además resulta que cada vez que se haga una venta pues
también según dice el libro hay que tener en cuenta que será un
comercial que va a tener digamos una aportación dineraria porque va a
comisión de las ventas que hace él Entonces él aporta quién es el
comercial que ha realizado esa venta así que al procesar la venta habrá
que incorporar y por eso aparece aquí Bueno pues que es que como los he
quitado ahora no me deja escribir Aparece el sistema de recursos humanos
porque hay que incorporar quién es el comercial que ha realizado esta
venta en los datos de la venta para que esa persona se lleve un porcentaje
de esa venta Eso lo anota el cajero, el cliente tiene interacción con el
cajero si esto lo pasáramos a una venta online todo esto desaparecería El
cajero, el encargado habría un administrador que sí que está haciendo la
gestión de usuarios o parametrizando el funcionamiento de la aplicación
para admitir yo qué sé Más usuarios, más vendedores etcétera es decir
podría cambiar y los perfiles de uso también podrían cambiar y son
diferentes en cada aplicación eso es evidente Ahora insisto en este
comienzo del desarrollo no me parece muy constructivo ni que aporte grandes
elementos el definir o distinguir entre todos esos perfiles Sino que creo
que es mejor para no emborronar esto y sobre todo en la evaluación poner
un usuario genérico a no ser que digamos el caso de uso esté dirigido a
matizar o definir cuál es ese perfil o a construir precisamente el perfil
de uso para otras funcionalidades de la aplicación No sé si me explico
¿Vale? Bueno, ¿Alguna pregunta más? Aquí no Una vez que hemos hecho
esto Una vez identificados todos esos casos de uso En el siguiente paso lo
que vamos a hacer es tomar cada caso de uso y desarrollarlo en paralelo Y
eso es lo que hacemos nosotros también en la evaluación y eso es lo que
también hace el libro una vez que define cuáles son los casos de uso toma
uno concreto el de procesar venta Y empieza a desmenuzando sigue haciendo
el análisis y luego pasa al diseño pero es que mientras tanto hay que
tener en cuenta una cosa Que esto es la funcionalidad y estamos siguiendo
haciendo la traza de la funcionalidad de este caso de uso pero la
aplicación no es sólo la funcionalidad del caso de uso Es que hay otra
software, hay más código que permite funcionar a este caso de uso y
también a éste y organizar determinados elementos de información que
utilizan cada uno de estos casos de uso Es lo que yo denomino código de
gobierno de la aplicación y bueno y los otros casos de uso o sea que
también no sólo hay interacciones entre el código que forma parte de
este caso de uso para su desarrollo De sus elementos entre sí sino que
también hay interacciones de ese código del caso de uso con el gobierno y
aún más he dicho al principio que el objetivo no es hacer o desarrollar
código para que esto funcione Sino que ese funcionamiento debe tener unas
características cualitativas la de la simplicidad y comprensibilidad, la
de la flexibilidad o adaptabilidad y la de la independencia funcional Para
eso vamos a tener que hacer primero una abstracción de todo lo que vayamos
a desarrollar que era esto, esta era la aplicación en el ejemplo de este
año jeflota Vamos a primero decir vamos a ver todo lo que desarrollemos
tanto de el gobierno como de los casos de uso Todo esto no tiene que
ocuparse va a tener la responsabilidad de conectarse o de presentar las
cosas con el usuario Es decir hay código que funciona o sea necesariamente
tiene que funcionar con el caso de uso o con el gobierno Hay código que es
sólo para presentar y recibir información con el mundo exterior del
funcionamiento de la aplicación Es lo que denominamos el código de la
capa de presentación para entendernos la interfaz de usuario más o menos
Además hay otro código que son lo que se denominan los servicios
técnicos Que establecen pues diferentes operaciones y funcionalidades, sí
acciones más que funcionalidades digamos de bajo nivel Como librerías
matemáticas cosas así entre ellos sería el código que permite conectar
por ejemplo ese actor de apoyo externo que hemos visto ahí calculador de
impuestos Pues ese código el caso de uso el código que desarrollamos del
caso de uso no debería preocuparse de qué aplicación Si es contaplus o
si es yo que sé cualquiera con qué aplicación me tengo que comunicar y
de qué forma le tengo que pasar los datos etcétera Eso es un acoplamiento
que va en contra del funcionamiento de la independencia funcional Así que
si yo decido que esto está fuera el conectarme con esto no debe ser
responsabilidad del código que vaya a construir Y por eso voy a
desarrollar una serie de código que me permite conectarme con este o con
otros Por ejemplo otro de los servicios técnicos sería el servicio de
acceso a los datos El funcionamiento de este caso de uso no debería
preocuparse, no forma parte de la funcionalidad de su responsabilidad como
el para qué se usa esa aplicación Si guardo los datos que voy a usar
dentro de ese caso de uso, si los guardo en ficheros, si los guardo en una
base de datos relacional Si es una base de datos de objeto, si lo guardo en
tablas o como diablos lo guardo Eso no es responsabilidad, pero voy a tener
que acceder sea cual sea la forma en que los vaya a guardar y cómo se
gestionan esos datos O el guardar y obtener esos datos los voy a tener que
usar Así que un primer paso para conseguir esa independencia es decir a
ver qué no es esencial para el caso de uso Pues todo esto que es de la
capa de presentación y todo esto incluido el acceso a los datos se guarden
donde se guarden Que es lo que digo la capa de servicios técnicos y esto
es lo que voy a empezar a analizar Y eso lo tengo que tener clarísimo
desde este punto Que ni nos importa el cómo se transfiere la información
desde el actor al funcionamiento del caso de uso Ni como el caso de uso se
la presenta al actor, etc. Otra cosa es la estructura, la línea de
funcionamiento que obliga del caso de uso o del funcionamiento De cualquier
parte de la aplicación, del software que estoy construyendo Que obliga a
maniobrar o reaccionar de manera distinta al actor Entonces lo primero que
hay que tener claro es esta división que ni es una arquitectura ni es nada
que se le parezca No es modelo vista controlador, no es esa estructura o
estilo arquitectónico No tiene que ver con eso, bueno tiene que ver porque
es cercano y comparte determinadas ideas de separar lo que es el negocio de
la presentación A esta capa que nos queda aquí es sobre la que nos vamos
a dedicar, se llama negocio, la capa de negocio Y esto separar el negocio
tanto de la presentación Separar el negocio tanto de la presentación como
de los servicios técnicos, aislar esto es el primer paso fundamental para
conseguir esa independencia funcional Y es lo primero que hay que asumir
desde el principio Bien pues yendo a dentro de esa separación en casos de
usos La primera parte del análisis o una de las primeras es obtener los
requisitos funcionales Y para eso tenemos que modelar cuál es el
funcionamiento deseado o obtener esos requisitos, esa lista de requisitos
del SRD Que se veía en introducción a la ingeniería de software La lista
esa de requisitos funcionales pues una forma de obtenerlo es hacerlo con
estos pasos Uno de ellos es la escritura del caso de uso La escritura del
caso de uso que lo que está buscando es establecer cuál es la secuencia
en las interacciones entre el actor y el sistema Pero aparte de lo que
acabo de decir de que estamos tomando sólo la capa del negocio Es que el
actor que es el que maneja el uso o la utilización del software, del caso
de uso El actor está interaccionando con una pared Aquí es donde estaría
esa interfaz de usuario Él no tiene ni idea de lo que hay aquí dentro y
por supuesto ni muchísimo menos de si esto interactúa con sistemas de
apoyo externo Él no tiene ni idea de si hay una colección de elementos de
información aquí dentro Él no ve nada de eso Entonces esta interacción
que se está representando aquí primero establece una secuencia En cuanto
a las interacciones que yo denomino estímulo Y la respuesta del sistema
Pero que quede bien claro que el actor no sabe lo que hay aquí detrás
Apenas sabe lo que hay aquí dentro tampoco Simplemente ve una lámina muy
fina correspondiente a la interfaz de usuario Que puede ser una pantalla,
pueden ser los elementos señaladores o el teclado etc. Podría ser un
lector de código de barras en algunos casos Podría ser un lector RFID
Puede ser lo que sea Lo único que estamos representando aquí es que el
actor traslada información No nos metemos en cómo Y esos son los detalles
técnicos que hay que evitar en esta representación Porque conceptualmente
no tienen cabida Entonces El caso de uso o la escritura del caso de uso
Debería comenzar con para qué quiere utilizar el sistema el actor El caso
de uso comienza cuando el actor quiere o pretende hacer determinada cosa
Esa decisión, esa voluntad es lo que transmite de alguna manera Y llámese
seleccionar una opción dentro de un menú Llámese arrancar un determinado
módulo dentro de la aplicación Esos son detalles técnicos que no nos
metemos en cómo Pero lo primero que tiene que trasladar al sistema es qué
quiere hacer Para qué quiere usarlo Para qué el caso de uso Ante esta
noticia, esa información El sistema responde respuesta Bueno pues para
conseguir eso Te tienes que decir En este caso A qué cuenca pertenece la
nueva presa que queremos asignar O sea, el actor no va a hacer nada que no
le esté pidiendo el sistema Así que aquí va implícito En este diálogo
de interacciones Estímulo-respuesta Va implícito ese funcionamiento Para
hacer algo necesito que me digas tal cosa O que tomes una decisión y que
me traslades esa información El usuario traslada en qué cuenca Quiere
registrar la nueva presa que quiere dar de alta Muy bien, pues para poder
continuar y conseguir el objetivo El sistema le pide más cosas ¿Por qué?
Porque las necesita ¿Por qué las necesita? Porque el funcionamiento pasa
por que utilice esos datos Que sólo se los puede dar el actor Que es el
que tiene la intención de obtener ese resultado Así que el que va guiando
el cómo pasa Es este sistema de aquí dentro, lo que hay dentro Y
precisamente luego veremos que hay un rol funcional Que es el del
controlador Pero el actor por supuesto no va a ver que hay un controlador
Nosotros al modelar ese comportamiento Lo modelaremos con un objeto
conceptual Que llamamos controlador Y es el que está manejando, arbitrando
Cuál es la secuencia de pasos que tiene que dar Y que le va pidiendo al
actor Una vez que el actor en primer lugar le ha dicho Oye que lo que
quiero es esto ¿Vale? Y así sucesivamente Así que digamos que otra
recomendación Es que en las evaluaciones Las pongo precisamente por eso
Para evitar esa frecuencia de malentendidos Y errores en las respuestas Se
lean con cuidado Las fuentes de errores Que vienen después del enunciado
de cada pregunta Porque precisamente ahí está diciendo Qué es lo que no
hay que hacer Para evitar esos malentendidos Posiblemente si se está al
margen De todos los videotutoriales, etc. Puede que no se entienda por qué
se dice eso Y esos elementos causantes de error En las respuestas de los
enunciados de cada pregunta Vienen explicados el porqué En estos
videotutoriales En esta documentación O en estas manuales Que están en el
curso virtual ¿Alguna pregunta sobre la escritura del caso de uso? Ah,
bueno, otra cosa La escritura del caso de uso Se refiere a una única
línea de éxito Es decir, aquí no falla nada Aquí no hay ramificaciones
El actor quiere una cosa Entonces el sistema Le va preguntando que le dé
los datos Y no hay posibilidad de error Esas posibilidades de error O
bifurcaciones Que no sean la línea más frecuente Por la que discurre No
tienen por qué ser de fracaso Pueden ser otras líneas Que no son tan
frecuentes Eso es lo que se denomina Flujos alternativos Y se pide uno o
dos flujos alternativos Respecto a la línea principal de éxito Aquí,
insisto, no falla nada ¿Vale? Desde el principio hasta el final Y eso es
lo que se va a modelar Y eso es lo que se va a codificar luego Vamos a
hacer el diseño detallado Sobre eso No de las alternativas ¿Alguna
pregunta sobre esto? La has constatado ya Porque iba a preguntar por los
flujos alternativos Cuando hay varias posibilidades Bien ¿Está
contestado? Sí, sí Vale De acuerdo Bien Este diagrama Que ya he dicho Da
lugar a Estímulo Respuesta Etcétera Se puede parecer Mucho, mucho, mucho
Al diagrama de secuencia Que plantea en el libro Un poquito más adelante
Aquí en el diagrama de secuencia Que yo denomino De sistema Diagrama de
secuencia Del sistema Es una Como he dicho en la escritura del caso de uso
Es un diálogo De interacciones Entre el actor principal Y el sistema Como
una caja negra Es la pared esa que he dicho antes Y que el cajero no sabe
Lo que hay aquí dentro Para nada Ni puede saberlo Porque alguien que
utiliza una aplicación No tiene por qué saber Cómo está construida Y
entonces, pues Eso es lo que estamos viendo nosotros Cómo construir la
aplicación Y el usuario No tiene por qué Vamos, que no lo sabe en
realidad Otra de las cosas Es que el El libro Tal y donde Introduce este
diagrama De secuencia Ya le da nombre A esas interacciones A este estímulo
Le da un nombre Crear nueva venta O Una vez que El sistema le dice A ver,
empieza a decirme los artículos Pues entra en este bucle Y Le da un nombre
A introducir nuevo artículo Agregar línea de venta Artículo y de
cantidad Etcétera ¿Vale? Esto está ya muy cercano Al diseño A la
definición Haber nombrado Cuáles son las funciones O los métodos De los
objetos Aunque todavía pudieran estar En un estado incipiente De objetos
conceptuales Pues ya, digamos Se está acercando demasiado al código Por
eso yo me resisto A meter esto Dentro de lo que es Ya la parte La
disciplina de diseño Pero, sin embargo Después de esta interacción Este
juego de Estímulo-respuesta Como he dicho Se puede asemejar a esto Y nos
puede dar una Idea De cuál es esa secuencia De acciones Pues el cajero
Dice que una nueva venta O quiere realizar Una nueva compra Muy bien, pues
el sistema Le solicita Las respuestas de esto Se ponen en la herramienta Lo
pone ya directamente En línea punteada Dime qué artículos Bueno, pues El
artículo primero Meto este Que tiene este identificador Pero que no quiere
decir Que sea el nombre de Alcayata O que sea el código De barras Aquí en
este lado No me preocupo De cómo se obtiene esto De hecho El actor no
tiene Ni la más remota idea De que el artículo Tornillo Tiene como
identificador El 4354 Por ejemplo No lo sabe Pues a lo mejor Si fuera una
En el caso del libro Es que se va a la estantería y coge el artículo en
sí El cómo lo identifica El cajero dentro de la caja Tampoco nos importa
Es un detalle de bajo nivel Un detalle técnico Y al final Al sistema lo
que le llega Insisto, aquí está la interfaz De usuario Y aquí le dice
que son tornillos Como he dicho Y aquí le llega el 4355 A lo que hay aquí
dentro Entonces son mundos totalmente apartes Totalmente inconexos Aunque
estén manejando Conceptualmente la misma información Pero necesariamente
Tiene que ser así Otra cosa Como estamos aprendiendo A cómo realizar esto
Con estas cualidades Que he dicho de independencia funcional
Comprensibilidad Y adaptabilidad Vamos a suponer El sistema Con un
funcionamiento Unifilar Es decir Sólo Puede haber Un Objeto Activo
Mientras en el funcionamiento Sólo uno Y mientras esté activo ese Los
demás no están haciendo nada No hay un funcionamiento Concurrente No
vamos a considerar De momento Ni en esta asignatura Digamos de aprendizaje
Al final del libro Sí que hace Al explicar precisamente Cómo se
implementa Una caché Para mantener el precio De los productos En la
colección Y utilizarlo Pues se utiliza Un Objeto, una clase Que está
constantemente activa Y está en funcionamiento Concurrente con todos los
demás En todo lo que Veamos tanto Del libro, la asignatura La evaluación,
etcétera Sólo funciona Un objeto a la vez O una instancia Y hasta que no
termina No devuelve Un funcionamiento unifilar No hay Digamos Patrones de
observadores Registradores de evento Atención Agentes que están
pendientes De que se produzca determinada Evento, interrupción En las
rutinas Ese comportamiento No lo vamos a contemplar de momento Porque lo
que estamos aprendiendo Es cómo desarrollar El código de manera que sea
Así de independiente Una vez que sepamos eso Ya podremos aplicar Otra
serie de mecanismos Y alternativas Que podemos utilizar Vamos a ver En el
desarrollo actual Hay frameworks Donde se inyectan Dependencias
directamente Y se hace todo Este desarrollo de una manera Bastante más
automatizada Pero haciéndolo así Aunque sea De esa manera De alto nivel y
tan automatizado Podemos seguir Cometiendo exactamente los mismos Errores
que estamos intentando Aprender a evitar En esta asignatura Podemos hacer
acoplamientos Brutales entre El funcionamiento de distintos Objetos Que nos
impidan Hacer ninguna modificación En el código que hemos desarrollado Si
queremos hacer cualquier Variación, incluso aunque funcione La mayoría de
los Errores que se producen Digamos en las respuestas De la asignatura es
que ni siquiera Se es capaz De expresar Cómo funciona Eso Pues será por
dificultad De representación con el UML O será por lo que fuera Pero es
que aunque funcionara Aunque digamos Se Se invocara Correctamente A
determinados métodos de un objeto Para que realizar una Tarea y con ese
Resultado se pudiera hacer otra Y entre todas esas tareas se consiguiera El
objetivo que se está pretendiendo Conseguir Aunque se consiga transmitir
eso O representar eso Además Ese funcionamiento que acabo de describir
Debería ser Funcionalmente independiente Comprensible Y adaptable Bien,
pues continuo Digamos que Estaba diciendo Esta misma secuencia Que he
puesto aquí La podemos Representar mediante este Diagrama de secuencia del
sistema Teniendo muy en cuenta Que esto es una caja negra Que el actor No
ve el interior Ni la composición De esto dentro, pero sí que nos está
dando Una pauta de la secuencia Primero esto, después esto Después esto
Lo que necesita Es esto La información Que necesita el sistema Para
continuar es esta Para parar Digamos ese bucle de recogida De productos De
los que está comprando Necesita Esta información para parar Y A
consecuencia Le dice Cuánto es el total Para que haga el pago Entonces El
actor realiza el pago Aquí dentro Se harán los procesos Que se
administran y el resultado Será El recibo Como que se ha registrado Y
terminado la tramitación De esa compra o de esa venta No hay una pregunta
en la evaluación Que corresponde a esto Pero este diagrama Creo que puede
ser De utilidad Para concluir O registrar Esta secuencia que hemos
planteado Aquí, que sí es una pregunta Y para pasar Al siguiente Que
sería el modelo de dominio Antes de ello Insistir En que La interacción
Siempre se produce entre El mundo real Del actor Que tiene la intención,
la voluntad De usar la aplicación Para obtener Un resultado Concreto y
final Y todo esto se realiza A través del hardware La interfaz de usuario
El código adaptador Que traduce Lo del mundo Del actor Lo traduce en el
mundo Los identificadores Objetos, elementos De el sistema Del código De
la capa De negocio ¿De acuerdo? Entonces Hay que olvidarse De que el
sistema Le mande Al actor Una invocación De cualquier función O cualquier
elemento Que sea código Esa información Se la mandará Como sea A la
interfaz de usuario Y en la interfaz de usuario La traducirá En algo que
sea legible Y entendible por el actor Esa es la Función, la
responsabilidad De la interfaz de usuario De la capa de presentación Pero
ni en el Ni en el modelado conceptual En el modelo de dominio Ni en Luego
en la implementación En el diseño El actor no va a recibir Invocaciones a
funciones Porque no las tiene Ni utilización De datos O de códigos
Estructurados Porque él no estructura La información En ningún Código,
en ningún dato estructurado ¿De acuerdo? Eso hay que tenerlo Muy clarito
Así que llegaremos A la construcción del modelo de dominio En el modelo
de dominio Hay que poner Quien es el actor Que interactúa Ese interactor
Ese actor La interacción que pueda tener Ese actor Es la única Relación
que puede tener Un significado De acción Verbal, digamos Porque es el
único que tiene Voluntad Y puede hacer algo ¿Contra quién puede hacer
algo? Pues si no conoce Ningún componente Del software De los mecanismos
De funcionamiento en los que está Constituido Interiormente el sistema
¿Con quién puede interaccionar? No puede interaccionar Absolutamente con
nadie Más que Con el resultado Que está buscando Es lo único Que podría
conocer conceptualmente Hablando Es decir Si el cliente Lo que quiere es
Comprar Pues la relación Es con la compra Los datos de la compra El libro
lo llama venta Porque lo está viendo desde el punto de vista De la tienda
Pero no puede Relacionarse Ni con el controlador Ni con El sistema Tienda
Las explicaciones En los video tutoriales Ya he explicado que este
Correspondería al controlador De nivel superior Etc El actor Solo puede
relacionarse Con el resultado Que está buscando Mediante una relación Que
es la única que puede Significar una acción Un verbo Etc El resto de
relaciones Entre los objetos Se refieren a Que contenido tienen De manera
que Gracias a ese contenido Porque ninguno de ellos tiene Funciones
Métodos Son solo atributos Las relaciones Son exclusivamente
Prácticamente Son de Contenido De que algún elemento Es un componente De
otro Objeto No me gusta llamarlo clases Porque el concepto está Muy
cercano a lo que es el código Entonces esto como no es Código Me gusta
más llamarlo objetos conceptuales Estas relaciones Son Suelen ser de
contenido Por ejemplo la venta A pesar de que tenga estos datos De la fecha
y la hora Pues seguramente habría Que meter aquí como he dicho antes El
nombre del vendedor O el código del vendedor Para que se le diera una
comisión Esto Dice que está capturado en No es un verbo Esto capturado en
Significa ni más ni menos Que el controlador Está Construyendo Una
instancia de venta Y por eso captura Esa instancia de venta Se va
rellenando con los datos Y ese Esos datos es el objetivo Que está buscando
precisamente El actor Y como es un componente Del controlador Pues se queda
ahí y por eso dice aquí Que lo captura Y no es que le lance un gancho Y
Se lo asigne O se lo absorba como componente Es que desde el principio Ya
es un componente suyo El registra completas No está diciendo más que Este
registro de ventas Va a tener Esta venta Aquí y esto a su vez Es un
componente El registro de ventas El controlador este Es un componente Del
controlador de nivel Superior Vuelvo a decir Porque es un componente Porque
antes de empezar El caso de uso El controlador De nivel superior Ha creado
este Objeto El registro de ventas Y Ya es un componente suyo El registro de
ventas Cuando el actor le dice que Quiero comprar Crea el elemento Venta
vacío Y ya lo tiene dentro Cuando La tienda Cuando todo esto termina La
tienda Tiene El objeto O la instancia del objeto controlador Con los datos
de la venta Así que No es que lo capture Porque ya lo tenía Es que
contiene Al controlador De acuerdo Está diciendo evidentemente Que una
venta contiene Varios ítems vendidos Cada uno con su cantidad Y el
contenido De estos Ítems vendidos Además de la cantidad Viene Descrito
precisamente Por Lo que denomina especificación del producto Que serían
Las características del producto Fundamentalmente Su precio Porque claro,
para hacer la venta Tengo que saber qué precio tiene Cada unidad Por
ejemplo, así que me llevo 5 tornillos Y el precio de cada tornillo Es 10
céntimos Vamos a poner por caso Pues eso es información Que está
contenida aquí Pero No es lo mismo O sea Línea de venta Tiene cantidad Y
en este caso Pues tendrá una instancia De especificación del producto Una
instancia Evidentemente la instancia De la colección Correspondiente al
producto que ha comprado Pero en otros casos No tiene por qué ser así
Puede venir Descrito pero no ser del mismo tipo No son exactamente iguales
¿De acuerdo? Entonces Lo de que sean del mismo tipo Ya hace referencia Al
código, a que esto sea una clase Y que lo que hay aquí No sea exactamente
de esa clase Que pueda tener La misma información Por lo tanto sigue
estando descrito Por esto pero no es de la misma clase ¿Bien? Bueno pues
Aquí si veis Como se implementa Pues sí, va a meter un elemento De
especificación del producto Correspondiente a esto Así que Ya sabemos De
qué forma Se completa Y se construye precisamente Lo que está buscando el
actor Así que esto Es el El modelo de dominio Que está explicando De qué
manera se consigue ese Objetivo Del caso de uso O sea, ese objetivo buscado
por el actor Al utilizar la aplicación Lo del catálogo de productos Es
digamos Un recurso normal Porque si yo tengo una colección De precios de
productos Necesito digamos Como una encuadernación Para manejar esa
colección De precios de los productos ¿Vale? Pues la encuadernación Que
permite acceder A los elementos De esta colección Es el catálogo Así que
el catálogo Contiene la colección Con todos los elementos ¿Qué es una
colección? Se ve aquí Un catálogo contiene Varios, una colección de
elementos De especificación De producto ¿De acuerdo? ¿Alguna pregunta
sobre esto? Nada Está bien Esto es lo que hay aquí Podría parecer Que
esto es muy específico Del caso de uso De venta, de hacer una venta De
procesar venta Vamos a abstraer Y por eso Os pongo esa Digamos modelo, esa
plantilla Vamos a abstraer A cualquier caso de uso O la mayoría al menos
Por eso creo Esa plantilla Hemos dicho que El funcionamiento es Unifilar No
hay concurrencia, etc. De manera que al final En la Vamos a ver En el
funcionamiento y en el diseño Del caso de uso El actor Aquí estará La
interfaz de usuario ¿De acuerdo? El actor Va a interaccionar Únicamente
con el Controlador Para conseguir su objetivo ¿De acuerdo? En el modelado
conceptual En el modelo de dominio El actor sólo se relaciona Con el
objetivo que está buscando ¿Por qué? Porque no conoce Todo lo demás En
la implementación Es el controlador El que está Sólo uno Un único
controlador Porque claro, si no No hay nadie Ningún objeto Que pueda
discernir A quien se dirige el actor externo ¿De acuerdo? Por eso digo que
no hay No hay escuchas No hay objetos que registran eventos Y según el
registro El evento que estén registrando Hacen una llamada a uno u otro
Vamos a Pensar en un funcionamiento Unifilar Donde el Actor Se comunica a
través de la interfaz De usuario sólo Con el controlador Ojo, esto es en
la implementación En el diseño, insisto En el modelo de dominio Sólo con
el objetivo que busca Sólo con el resultado que está buscando ¿De
acuerdo? Bien Vale Pues sólo puede haber un Objeto Controlador Que sea el
que organiza Oye, que ahora necesito que me digas Qué producto Vas a
comprar Oye, que me digas el siguiente Oye, que Este es el total Que me
hagas el pago Para finalizar la venta Eso, ese guión Sólo puede estar en
El controlador De hecho, el rol de Controlador es El de organizar El
funcionamiento Del caso de uso Y que otros objetos Se van a utilizar Y en
qué orden intervienen Y cómo prestan Sus servicios Porque evidentemente,
no todo Lo hace el controlador Cada uno tiene su Función Y eso es lo que
tenemos que Definir en el diseño Entonces Con eso, lo que estaba diciendo
Es que Abstraigo a una Plantilla Donde El actor Se relaciona única Y
exclusivamente Esto es el modelo de dominio Un actor Se relaciona única y
exclusivamente Mediante algo Que sí que puede ser Un verbo, una acción
Porque Representa la iniciativa Y la voluntad Del actor de conseguir Este
resultado o este objetivo Del caso de uso Ese objetivo O ese resultado Es
el controlador Único El que se va a encargar De organizar el
funcionamiento Y secuenciar las acciones Para que Se construya Ese
resultado Y por eso es La relación que hay entre Esto y El controlador Y
el resultado Y ese resultado Se va a obtener Por la información Que está
enviando O que está Transmitiendo el Actor Y por una serie de Información
Que maneja internamente El sistema Lo que denomino el modelo de datos Que
puede ser uno Objeto o cincuenta Los que sean necesarios Esto es la
información Que se necesita Para construir el resultado Así que Es
fundamental para explicar Cómo funciona El caso de uso Desde el nivel
conceptual Estas relaciones Del contenido Del resultado Buscado por el
actor Con el modelo De datos Quien se encarga de Establecer, recoger La
información que se necesita Y la que aporta el actor Para construir El
resultado que está buscando El controlador Está manejando Pero aquí no
ponemos manejos Así que No valen las relaciones En el modelo de dominio
Las relaciones usa Crea Utiliza Etcétera No valen Aquí son sólo
relaciones De contenido O que Representen El contenido de aquí Proviene
Del contenido que hay En estos objetos Está descrito Por O describe
Determinada cosa Y eso quiere decir Que ese contenido Necesario para
construir Este resultado Proviene de aquí Así que estas relaciones De
contenido De descripción De proveniencia Son fundamentales para decir Que
esto funciona así Esta es la lógica del funcionamiento Y de todo ello se
va a encargar El controlador Que se puede llamar como queráis Pero tiene
que tener ese rol De ser único Y de Tener capacidad Para manejar El
funcionamiento De esto Entre otras cosas En que Tiene como Componente este
resultado Es suyo ¿De dónde viene el controlador? ¿Y de dónde vienen
los datos? Que a lo mejor unos se crean aquí Dentro del funcionamiento Del
caso de uso Pero otros se crean Y se están compartiendo transversalmente
Con otros casos de uso En otros lugares, etc. Dentro del negocio ¿De
dónde viene todo esto? ¿De dónde sale? No sale de la chistera Sino que
cuando se inicia El caso de uso Esa petición llega aquí Al controlador De
nivel superior Lo que yo llamo en muchas ocasiones En los ejemplos, nivel
aplicación Y entonces El nivel aplicación tiene esa inteligencia Esa
programación De que lo que quieres Es esto Pues entonces lo que vas a
necesitar Es el catálogo de precios Y crea El catálogo de precios Y se lo
pide al módulo Ya estamos hablando de arquitectura Al paquete Que está
manejando Los productos y el catálogo De precios de los productos Y
rellena La colección de elementos Que está manejando Este catálogo Con
los precios de cada producto Y una vez que Ya tiene esto, que es la
información Que va a necesitar este El controlador Para rellenar Este
resultado Que busca el actor Junto con la información que le va a producir
El actor Entonces una vez que tiene esto Se lo Crea El controlador Y en su
constructor Le mete como componente Todos esos datos El modelo de datos
Así que una vez que crea El controlador del caso de uso El controlador de
nivel superior Ya no escucha más Delega El control en el controlador Del
caso de uso Y este ya no funciona Hasta que el controlador del caso de uso
Haya terminado Y devuelve el control Al nivel superior de funcionamiento
Por eso digo El funcionamiento Tanto global Como en el caso de uso Es
unifilar Habrá un árbol De funcionamiento Pero en cada momento Nos vamos
por una rama De funcionamiento ¿Vale? Y si en el caso de uso estamos aquí
Pues aquí se harán las cosas que sean Y cuando termina, pues estamos en
este punto Que este es el final de funcionamiento De este punto, pues
vuelve al siguiente Y así sucesivamente Entonces hay un esquema También
de funcionamiento global Que es jerárquico Está jerarquizado Puede ser un
esquema arbóreo Puede ser lo que sea Entonces esto es una plantilla
Digamos como una Abstracción para aplicar Esto que hemos visto aquí Para
procesar venta A aplicarlo a los distintos Casos de uso que más o menos
Van a tener un aspecto Muy parecido a esto Lo que pasa es que los objetos
Pues serán diferentes Habrá más colecciones o menos colecciones Pero
siempre habrá Un controlador único Un resultado buscado El resultado
buscado Se descompondrá a lo mejor En otros ítems En otros elementos O
podrán ser dos No tiene por qué ser uno único Etcétera Es decir, podrá
cambiar un poquito La cosa pero el esquema general Responde a Esta
plantilla Sin todas las monigotes y borrones Que están puestos ahora De
acuerdo Bueno Como decía anteriormente El siguiente paso a esto Es Ya
empezar con el diseño detallado Así que Ya podemos tener Bastante clarito
En cómo va a funcionar eso Para tener esa claridad En cómo funciona Es
Bastante importante Entender Y haber construido Concebido adecuadamente
Estos elementos De aquí Estos objetos conceptuales La mayor parte de estos
Objetos conceptuales Van a pasar A formar parte directamente De la
implementación Del diseño Estos atributos Que no tienen tipo Porque esto
es conceptual Y no hay un tipo de código Pero que al pasarlos Al diseño
Sí que van a tener su tipo Y además tendrán sus métodos De manera que
estos Métodos sólo podrán acceder A su contenido Y este Este objeto Si
tiene una relación Sí que podrá invocar Pues por ejemplo El controlador
Sí que podrá invocar Métodos De este objeto Y los métodos de este
objeto Sólo pueden manejar Su contenido Y así sucesivamente De acuerdo
Bien, pues Incluso cuando estamos haciendo El modelo de dominio He estado
hablando De un controlador De nivel jerárquico superior Es que ya
tendríamos Que estar pensando Un poco en cómo se organizan Los objetos
Conceptuales Que luego van a ser de código Cómo se organizan en lo que
Denominamos Una estructura Una arquitectura Esto va a ser El dominio del
negocio Esto sigue siendo la capa del negocio Y aquí estoy poniendo El
código correspondiente A la capa de los servicios técnicos Vale, bueno
Podríamos tener un módulo Que fuera ventas Donde estuvieran Realizándose
todas las operaciones Correspondientes al Procesamiento de las ventas En
este Arquitectura En este sistema Que es el que viene en el libro Punto de
Venta, PDV Bien Pues habrá un controlador Y el controlador Es el que crea
la venta Y la venta Como hemos visto en el modelo de dominio Se constituye
con Líneas de venta, es decir Donde se guarda qué objeto Se está
comprando Por lo tanto su precio Ojo Estoy diciendo qué objeto se está
comprando Y no es El identificador Porque en los datos que se recogen de la
venta No me vale de nada que sea El identificador, un código de
Identificación de los tornillos Que no sirve para nada Yo lo que tengo que
guardar Como los datos de la venta Es el precio El nombre, la descripción
Etcétera El identificador también porque es una Un anclaje Digamos
redundante En parte para que No haya peligro de pérdida de información Y
en parte para Obtener un desacoplamiento Eso en uno de los Video tutoriales
lo explico Un desacoplamiento en el caso De que La formulación Que
utilizamos para codificar cada uno De los elementos la queramos cambiar
Para no hacer depender Todo este funcionamiento que depende De ese tipo Lo
abstraemos en una clase separada Y entonces lo único que tendríamos Que
hacer es cambiar el tipo Del contenido de esa clase Y no todo Lo demás
Esto es un mecanismo Que se denomina de indirección Para desacoplar
objetos entre sí ¿De acuerdo? Pero aparte de eso Resulta que para
calcular El total vamos a necesitar El cálculo de impuestos Y anda Pero si
eso es un elemento Es un objeto Un actor de apoyo externo Que está fuera
¿Cómo diablos Se implementa esto? ¿Cómo represento ese funcionamiento
En el diseño? Es que no hay que preocuparse Pero Desgraciadamente Todas
estas explicaciones De cómo se hace eso Aparecen al final del libro Con lo
cual Durante el principio que estamos Intentando comprender esto La
comprensión Es gracias a una especie De acto de fe Bueno, esto se
resolverá Mediante un determinado Mecanismo Del código Un mecanismo
software Y entonces Surgen estas dudas Y creo que Esta es la causa De no
saber muy bien Cómo colocar estas cosas Al implementar el diseño Lo
explico ya de entrada Si venta Resulta que tiene que acceder A un Objeto A
un proveedor de servicios Externo Un actor de apoyo externo Pues lo que
necesita Es un Adaptador Un atributo Que le permita Esa conexión Ese
adaptador proviene O es del tipo De una interfaz Interfaz Que permite
especializar A quien Se va a conectar ¿Cómo se consigue esto? Muy bien,
tenemos Una factoría De servicios Una factoría abstracta De servicios Un
objeto Exclusivamente de código No forma parte De los elementos
conceptuales Este Objeto Esta clase En realidad Está Está construida De
tal manera Que desde cualquier punto Del código Gracias a estas Objetos
Estes Atributos estáticos Puede accederse A él Desde cualquier punto Del
código Desde cualquier momento Se puede acceder A esta factoría De
servicios, abstracta De manera que Como este necesita Un acceso Lo que hace
es pedirle a la factoría Abstracta Que le dé un Adaptador Del tipo
adaptador Cálculo de impuestos Este Adaptador cálculo de impuestos Así
que esta factoría Crea el adaptador Crea una vez El adaptador Cálculo de
impuestos Y el adaptador Específico, especializado Para conectarse Con
este A través de esta fachada Esta fachada Está en la capa de servicios
Técnicos Y esto está en el negocio Es decir que si yo necesito Acceder
Para calcular El total Necesito acceder al calculador De impuestos Pues eso
Puedo acceder a ello gracias A que al crear Este elemento Se ha Activado
una llamada A GetInstancia De la factoría De servicios Que GetInstancia le
está pidiendo Un Una interfaz De tipo Adaptador de cálculo De impuestos
Una interfaz Cuya realización Es precisamente la que se comunica Con esta
Actor De apoyo ¿Vale? Lo mismo pasa con Los productos El catálogo de
productos Es absurdo Aunque los productos y los precios De los productos
estén todos guardados En ficheros Hemos dicho anteriormente Que esos
ficheros yo no me tengo Que preocupar O el negocio No debería Y la parte
del caso de uso Ni siquiera al gobierno Pero bueno todavía más La parte
del caso de uso Cuya responsabilidad es registrar Los datos De cada una de
las ventas De cada uno de los productos Que se están vendiendo O comprando
No me tengo que preocupar Si los precios de los productos Los estoy
guardando en ficheros En bases de datos O un servicio web De información
Así que donde lo venda Donde lo esté guardando Que me da lo mismo En esto
que estoy denominando Almacén Y que estoy denominando un sistema De
información Que es externo Para comunicarme con él Tendrá su fachada Que
me tendré que construir Para esta concreta Si es una base de datos Y por
ejemplo hay 5000 productos No los voy a cargar todos En esta colección No
voy a cargar Aquí los 5000 productos Pues una de las opciones Sería esa
opción De caché Pero en cualquier caso Por ejemplo En esta opción De
caché que dice el libro Podría cargar En esta colección Los 50 más
utilizados Lo importante Es saber Que Que tengo También un servicio De
acceso A donde están Almacenados todos esos datos En el ámbito Exterior,
externo Y ese acceso Lo mismo que he dicho con el cálculo de Impuestos al
crear El catálogo de productos Se crea invocando A la factoría de
servicios Y con el Get instancia le digo Oye dame una Instancia del tipo
Interfaz De adaptador De productos Y con un Adaptador específico Para la
base de datos Donde estoy guardando este Muy bien pues hace exactamente Lo
mismo, crea el adaptador De productos Y del adaptador de productos Crea De
la interfaz Adaptador de productos Crea el adaptador Específico,
especializado Para esta fachada Que se conecta con la base De datos en este
caso Así que a partir de entonces Ya vamos a estar manejando Este
catálogo De productos y todos Los elementos de la colección Sin temer Sin
tener ningún Problema en Utilizarlos, entonces Conceptualmente Esto Está
completo Esto No está en ficheros Ni está en ningún lado No tenemos que
preocuparnos De que haya que buscarlo En un fichero o en una base de datos
Ni nada de esto, porque al implementarlo Tendremos aquí Ese servicio Que
va a acceder Al exterior Y va a obtener lo que necesite Si el
funcionamiento Maneja algún elemento Externo En el modelo de dominio No
aparece Nunca aparece Un objeto Un actor de apoyo Externo, jamás Si Es
necesario para el funcionamiento Algún elemento De información que esté
aportando El actor Externo, pues Se utiliza aquí ¿De dónde proviene
este? Vale, pues del Controlador de nivel superior Vamos a ponerlo así Y
este será El objeto con los elementos De información que son
imprescindibles Para Explicar el funcionamiento Del caso de uso Pero nunca
se pone El actor externo Ni por supuesto todos los mecanismos Que son
estrictamente Código de software Para acceder A estos elementos de apoyo
Externo. Si Conceptualmente es necesario Alguna información que provee
Este Actor de apoyo externo Pues lo ponemos Como elemento de información
conceptual Como un objeto conceptual Que proviene también De tienda Del
controlador Del nivel jerárquico superior Vale, bueno Pues como decía
Antes Antes de que el actor Le diga Que voy A registrar Las próximas
ventas Que me vengan O abro en el Cajero, en la caja Abro una sesión para
Ir metiendo las Ventas. Antes de que Aparezca alguna venta Lo que hago es
iniciar El Caso de uso diciendo que Abro sesión para Comprar o para vender
¿De acuerdo? Bueno pues El Sistema, la tienda El controlador del negocio
El general o lo que sea Depende del nivel en el que estemos En esa
jerarquía ¿Vale? Estará haciendo lo que sea Y una vez Que ya ha
terminado Lo que estoy intentando Representar aquí es A partir de ahora me
voy a dedicar A registrar las ventas Y esto es antes del Caso de uso Pues
para Registrar las ventas le llega Al controlador que está A la escucha,
que es el principal Digámoslo así Y entonces lo primero que hace es Ah
que para ventas voy a necesitar el catálogo De precio de los productos Muy
bien pues venga Me lo creo Vacío evidentemente Al principio porque es Una
copia ad hoc Muy bien pues En el constructor Este Catálogo habrá Un Ah
Get adaptador Una invocación A la factoría De servicios Que lo que está
diciendo Es factoría Get instancia Get adaptador de productos Le estoy
pidiendo A través de la Interfaz Adaptador de productos Uno específico
que sea Un adaptador de productos Para la base de datos, esta que tengo
aquí Y Obtengo Ese adaptador a través De este Que está digamos Accesible
desde cualquier punto Aunque estamos dentro Del objeto de la clase De la
instancia Perdón, la instancia Cprecios De la clase catálogo Precio de
productos Estamos invocando A esta Clase Y me obtengo una instancia Del
adaptador Aunque sea desde aquí dentro Y este aquí dentro Es un
componente De el Del controlador De nivel superior, así que En principio
Si no fuera porque este Es de accesibilidad global Gracias a ese método
Estático get instancia Y a este singleton Si no fuera por esto Esto que es
componente de este No podría acceder A este elemento porque no lo
conocería Mucho cuidado al desarrollar El diagrama De interacción Sea el
de secuencia o sea el de Colaboración Del diseño detallado porque es uno
De los errores más frecuentes Hacer invocaciones A métodos De objetos,
instancias De determinada clase Que no se conocen No se tiene acceso a
ellas porque No forman parte De un elemento Del objeto Invocante Así que
hay que tener mucho cuidado Con eso, solo esta Factoría que da acceso
precisamente A Y esta pertenece a la arquitectura O sea está totalmente
fuera del caso de uso ¿De acuerdo? Por eso digo Que es muy importante ya
tener un concepto De cómo está conformándose La arquitectura,
normalmente Este registro de ventas como hemos Visto aquí Este registro de
ventas Está dentro de un módulo Así que esto está cerrado Solo tiene
relación Con determinadas cosas Que estamos estableciendo aquí Pero no
puede tener Una relación de todos con todos Porque entonces tendríamos
Ese acoplamiento que estamos Intentando evitar, así que Esto está dentro
de un módulo Y no va a tener más conexión Que pues cosas Dentro de este
módulo Y poquito más Porque es lo que estamos evitando Que tenga
conexiones con más cosas Pues Estamos aquí El controlador principal Crea
un objeto Que es el catálogo y el catálogo Accede aquí, porque puede
Este es global Y obtiene un acceso A donde están guardados Todos los datos
Y a partir de ahí, bueno pues este Lo que hace es crear ese acceso Y ese
es el que devuelve Aquí. A partir de aquí Pues como este Está vacío Le
dice, bueno pues venga Accede al elemento de almacén Externo y Carga los
precios Muy bien El adaptador se puede conectar Con la fachada Y la fachada
Se conecta con la base de datos Con el fichero, con El servicio web o con
lo que sea Donde están guardados todos los datos Lo recoge Y ya crea esa
colección De especificación Del producto Vale. Una vez que Ha terminado
esto Esto no forma parte De un proceso de aquí Es que me ha pillado Dentro
de esta Línea temporal Pero no tiene nada que ver. Una vez que Ha
completado todo esto Y aquí Hay una longitud De duración De este proceso
Una vez que ha terminado este Proceso, entonces puedo invocar El registro
general Puede invocar Ahora crea el controlador Del caso de uso Regventas,
que es de tipo Registro ventas Y le mete En su Constructor Le meto el
catálogo De precios que he creado antes Así que el registro Ventas El
controlador Del caso de uso Tiene acceso total Al catálogo de precios Y
puede invocar las funciones Que pueda tener catálogo De precio del
producto No a los elementos De su colección Solo a los Métodos Del
componente Que tiene Puedo decir Cprecios .get Si éste Tuviera un get
Artículo id Pues éste puede hacer Una invocación A este método Porque
este método es de un componente Suyo Si no, no sería Cprecios Y le mete
Artículo id Lo va a tener que conocer Efectivamente Y el registro ventas
Va a tener que conocer de qué tipo es éste Para pasarle ese elemento De
acuerdo Bueno, pues lo mismo que Hay aquí en un diagrama de secuencia
Fijaos que En un diagrama de Secuencia Las Invocaciones a los Métodos Lo
que el libro llama Mensajes No se numeran No hace falta numerarlos Porque
esto ocurre En el tiempo éste Aquí No ocurre ni aquí, ni aquí Ni antes,
ni después de que ocurra esto Cada uno tiene que estar A la altura
correspondiente Si éste estuviera más No sé Si éste estuviera más alto
que éste No podría ser No se puede crear éste adaptador Antes de poderlo
invocar O sea que Ésta línea de tiempo Es fundamental Que se respete Y
poner Los objetos A la altura del tiempo transcurrido Que corresponde
Gracias a eso No hay que numerar Los mensajes O las invocaciones Cuando se
producen, en qué momento Lo cual está dando Una interpretación de la
dinámica Pero En los diagramas De interacción Como la representación Es
horizontal Pues no hay Una línea temporal Ni siquiera causal De cuándo se
producen Las llamadas O esos mensajes Y cuándo se retornan De esos
procesos Así que es obligatorio Numerar En qué orden se producen A ver Si
lo diré En qué orden se producen Esas llamadas a los mensajes De acuerdo,
vale Pues lo que estábamos diciendo Antes es que el encargado Le pide Al
controlador de nivel superior Que Abra la sesión Para registrar todas las
ventas Que vengan Entren en esa caja Entonces lo primero que hace Como
hemos visto anteriormente Es crear El catálogo de productos Lo que Hace
Como Primer Instancia En primer momento Lo primero que hace Es crear una
colección vacía De Las elementos de su colección Después Lo que hace es
Y esto es en el constructor Al crear esto Lo primero crea la colección
vacía Lo segundo, esto se puede intercambiar Da lo mismo porque es
irrelevante Lo segundo En este caso 1, 2 Se va Indexando Sangrando Los
mensajes Este mensaje se descompone En 1,1 que hace esto 1,2 Que hace una
invocación A factoría de servicios Al global A la clase esta Global Para
Lo primero es Crea el servicio Externo que es De tipo interfaz Adaptador de
productos Y Lo segundo que hace Es A ver Invocar Este servicio Externo Que
es para crear Un fichero en local Esto hace referencia A ver Todo esto Voy
a cambiar de Todo esto Todo esto es para que veáis Como se implementa
Bueno Como se implementa La caché En el anterior diagrama Habíamos visto
que se creaba El servicio externo Y ese servicio externo Ya quedaba
Adaptador de productos Perdón Este adaptador de productos Ya quedaba Aquí
Dentro del catálogo De productos Lo cual le permitía Al catálogo de
productos En el momento que lo necesitara Acceder a la base De datos
externa En este caso Implementando todo esto Que os he rallado en azul Lo
que estamos haciendo Es crearnos un fichero En local En un fichero indexado
Por clave de objetos serializados Esos Especificación del producto Esos
elementos de especificación del producto Donde están los Los precios
Entonces ahí guardo Unos cuantos Que sería El Con este acceso A la base
de datos externa Lo que hago es Una vez creado Este Adaptador de productos
Locales Y creado este fichero Lo que hago es lanzarle Un Run De manera que
esto está En bucle activo Esto es un objeto Que está activo En un Thread
activo Se abre una línea donde está Sincronizado para que no Haya en el
caso de que hubiera Concurrencia en el acceso Al almacén Para que no haya
conflictos En las modificaciones Y es del tipo Runable Es decir que está
constantemente Funcionando De manera que esto se queda Como digamos en
Espera activa o en funcionamiento Activo Mientras está funcionando todo
esto Para crear y actualizar Todo lo que ocurra En este Fichero Donde
estamos guardando En local Esos elementos Pero desde el punto de vista de
lo que nosotros Estamos manejando Estos elementos Estos elementos vamos a
considerarlo Tanto En el modelo de dominio Es decir en el análisis Y en la
En modelado Conceptual Como incluso aquí En el diseño detallado Todos
estos elementos Este fichero no por supuesto Pero todos estos elementos los
consideramos Dentro de la banda De negocio Y además Como si fueran objetos
en memoria Son objetos Digamos que son volátiles Que no tienen
persistencia La persistencia para guardarlos en fichero Se realiza con
Mecanismos de este tipo Mediante Este adaptador precisamente El adaptador
de producto Es como se implementa Que si hay alguna modificación Y quiero
guardarlo pues hay una instrucción Específica en el catálogo De
productos que a través De este adaptador de productos Accede al elemento
exterior Que será Un fichero o que sea lo que sea Y lo guarda
persistentemente O lo modifica de manera persistente Pero mientras tanto
Todos estos otros objetos son En memoria Y consideradlo así En memoria
Así que lo primero Sería Para hacer el diseño detallado Vamos a Tomar
Esto es lo que denomina Luego en las escrituras De los contratos Esto
sería Diguéramoslo así Una operación Para Explicar de una manera más
explícita Y formal incluso En qué consiste esta operación Sería la
escritura Contrato De la operación X Vale pues Sería En este caso sería
la escritura De la operación crear nueva venta Esto lo que está
significado Es que llega un cliente En ese registro Que ya está creado Y
está a la escucha En este registro de ventas Llega un cliente y dice Que
quiero comprar estos productos O determinados Productos Y eso le llega al
sistema No es esto lo que tenemos que implementar Como os he dicho Sería
este Diagrama Lo que pasa es que estoy haciendo hincapié Sobre que esto es
de todas estas acciones Que estoy viendo Esto es lo que denomino operación
Del caso de uso Procesar venta Muy bien pues vamos a ver Esto como se
Implementa en el diagrama De secuencia Pues el cajero Ojo En todas las
Diagramas Del diseño detallado Lo que aparece aquí no son clases Son
instancias Son instancias concretas de esas clases Así que Poned nombre A
todas las instancias Ponedle nombre El cajero Envía una señal A través
de la ayuda Acordaos De a ver que quiero Empezar una venta Al registro de
ventas Pues si quieres empezar una venta Lo que vas a necesitar es Que creo
un elemento de venta Y este sería el resultado Que está buscando en
realidad El actor Este elemento venta Que ya rellenaremos Sus datos Va a
estar formado por un conjunto De elementos Línea de venta Vamos a
denominarlo A ese conjunto Líneas de venta A ver, atención Aquí En el
tipo Se pone El tipo del elemento de la colección Esto es una colección
Quiere decir que esto Es un multiobjeto Esta estructura El tipo de esta
estructura Pues podría ser Un ArrayList O podría ser un ¿Cómo lo llama?
Un HashMap Creo que es así O podría ser Cualquier otra Así que esto Es
un multiobjeto Multiobjeto Y se pone Así con un doble Cuadrado El recuadro
este Descentrado del anterior Para hacer idea de que son Muchos Eso aquí
En el modelo de dominio no En el modelo de dominio No se pone Ese
desdoblamiento Entonces se pone El tipo La clase El objeto que se pone
aquí Se pone la clase De la que es cada elemento Insisto Que este
multiobjeto puede ser de la clase ArrayList Pero aquí se pone la clase De
la que es un elemento Y el nombre que se le pone aquí Es el de La
colección El de todos los elementos ¿Cómo llamo a la colección? Igual
que en el otro Lo llamo catálogo Pues aquí Lo llamo líneas de venta Lo
voy a poner LVS El nombre de la colección Y el elemento venta se llama V Y
el registro Este controlador se llama RegVentas Como digo, al iniciar Se
crea un elemento venta Y en el constructor de elemento venta Lo que hace es
crear la colección Vacía Cuyos elementos son de LíneaVenta de esa clase
Y lo voy a denominar LVS Para que se vea que son Varias líneas de venta
Esto mismo Con esto terminaríamos la operación CrearNuevaVenta Esto mismo
Esto es un diagrama de secuencia Como veis, las cosas ocurren en cada
Línea de tiempo No pueden ocurrir ni antes ni después El objeto que se
crea nuevo Se crea a la altura del Antes no existía Así que no se puede
Poner aquí y decir Créate Y que aparezca aquí Debería estar a esta
altura Y dejar bien claro Que antes no existía Y esto mismo Se puede hacer
con el diagrama De colaboración CrearNuevaVenta Llega al registro ventas
Aquí también se llaman Se nombran todas las clases Que invoca La
creación de un elemento Venta Y como Submensaje Del 1 se descompone En el
1.1 que a su vez Crea Este Multiobjeto Cuyos elementos Son de tipo De la
clase línea de venta Y que voy a denominar LVS ¿De acuerdo? Bien A ver,
hace mucho que no pregunto ¿Hasta aquí hay alguna pregunta? No Bueno Es
que no tengo la pantalla De los participantes Y solo veo a Carlos Vale Hay
otro Eso es Hay otro compañero Es que no veo su intervención A ver Sí Ya
veo Ah Bueno, continúo Se me sigue Viendo bien, ¿no? Sí Es que he hecho
alguna maniobra Por si hubiera ido La siguiente Operación, digámoslo así
De la que Estamos hablando sería desarrollar En realidad Todo el caso de
uso Es un continuo Detrás de esto Vendría el siguiente Que
desencadenaría Una secuencia De otras cosas El registro venta Llamaría a
otros Métodos De otros objetos Que realizarían otras operaciones Darían
un resultado En fin, haría otras cosas Y todo va en continuo Yo lo estoy
separando aquí Para simplificarlo En la evaluación y en las respuestas
Pues también se puede Separar Los diagramas de esta manera Dejando claro
que Los antecedentes son estos Y darles así Esa continuación Pero en
realidad Esto es un continuo La línea de tiempo no se detiene Hasta que
finalice Bueno, pues lo mismo que antes Este Bucle Donde se agrega cada uno
De los productos Se implementa en el diseño Para representarlo En un
Diagrama De Secuencia Así Si esto me hace caso No sé por qué No me hace
caso esto ahora Ahora sí Bien La orden o la invocación Insisto, a través
de la IU Aquí Este identificador Artículo ID El cajero No se lo sabe Ni
remotamente Puede a lo mejor estar pulsando Una determinada fotografía Y
esa fotografía Lo que desencadena es un Identificador Que ese
identificador la IU La pasa al adaptador Para que llegue al negocio Y
traduce ese identificador En un elemento Que sí se conoce Dentro del
negocio Y ese objeto pues sería Artículo ID Pues aquí estoy
representando Eso Que ID Es del tipo Artículo O de la clase ID De acuerdo
Muy bien pues Lo siguiente Sería que Una vez que le llega El identificador
Del producto que está comprando Y la cantidad Que es necesaria Pues Este
que insisto Llamarlos a todos Ponerle un nombre Spec Especificaciones Digo
que esto es un Multiobjeto pues entonces Lo voy a llamar Especificaciones
Espec I Ca Ciones Venta V y línea de venta Y esto se llama Línea de
ventas ¿Vale? Y este catálogo de productos Y este registro de venta Bueno
De acuerdo pues Esto le llega aquí Entonces ¿Qué es lo que necesita?
Porque lo que vamos a guardar Tenemos que tenerlo bien claro ¿Qué vamos a
guardar en El resultado que busca el actor? El precio La cantidad De
producto que se lleva Pues si la fecha Y la hora de la Compra y una serie
de datos Pero para cada uno de esos Productos como digo Hay que tener bien
claro Que lo que necesitamos es el precio De ese producto Evidentemente
también su descripción Su nombre En fin, lo que sea Eso estará aquí
Así que el que recibe Esa petición Le accede Al catálogo de productos
¿Por qué puede acceder al catálogo de productos? Porque es un componente
De registro de venta Que el nivel de aplicación Es decir la tienda Le ha
pasado cuando Le ha transferido cuando Ha creado Registro ventas ¿Vale?
Entonces por eso Porque es componente suyo Puede acceder al catálogo de
productos ¿Vale? Y como puede Pues entonces le dice a ver Dame la
especificación Del elemento del producto ID Que me ha dicho aquí El actor
El catálogo de productos Recibe esa invocación Y Accede a su colección
Diciendo Búscame El identificador De El elemento Especificación del
producto ID Encontrará uno Y ese uno Es el que hemos llamado Spec Y
devuelve de esa Invocación al catálogo de productos Y ese mismo Spec es
el que devuelve Al registro De ventas la invocación Del catálogo de
productos De haberse lo pedido A ver este buscar ID Es Un Método del
Multiobjeto De la estructura que estemos Buscando Así que si es un HashMap
Este buscar Se traducirá en un GET El objeto Clave Del HashMap Y entonces
buscará por su HashMap Que es una estructura asociativa Cuál es el
elemento y devuelve El objeto Digamos objetivo Especificación del producto
Sabéis que un HashMap Un asociativo Se organiza en un Key object Una clave
Y un content Vamos a llamarlo así Object Entonces esto sería Artículo ID
Espec Del producto Porque está pidiendo Búscame Esta clave Y entonces
cuando la encuentre Devuelve el objeto este Aquí Y a su vez esta llamada
Al catálogo de productos Devuelve esto Con ese Servicio De productos Que
tenía como acceso Como atributo Que le permitía acceder A la base de
datos o al fichero O lo que sea ¿Qué pasaría si esta función GET
Especificación ID No lo encontrara en su colección En memoria Esta
colección está en memoria ¿Qué pasaría? Pues no pasaría nada Este
código Que está dentro Del catálogo de productos Lo incrementaríamos Si
no lo encuentras Entonces vete A servicio de productos Y búscamelo allí
Con lo cual No lo encuentra aquí En los que están en memoria Pues a
través del servicio De productos continúa Esa rutina Lo busca fuera Lo
encuentra Lo trae Y lo devuelve igualmente Y aquí nadie se ha enterado de
nada Ni ha pasado absolutamente nada Seguimos con este mismo Elemento Como
digo Lo que estamos representando aquí Es la El flujo Único de éxito No
pasa nada que interrumpa El buen éxito De esto Ahora, si no se pone aquí
Que es lo que hay que hacer para llegar a ese éxito Evidentemente pues
claro que se interrumpe Pero Aquí no se van a poner bifurcaciones Sino que
todo va bien Todo va bien Si lo construimos todo bien también Bueno pues
ya Tenemos La especificación de este producto Donde tenemos La
descripción Tenemos el precio Y tenemos incluso De manera redundante si
queréis El artículo ID O el ID que estábamos buscando Pues una vez
Terminado esto Y fijaos que hasta que no se terminan Todos estos Procesos
No se invoca Otro Una vez terminado esto Pues entonces le dice A ver, pues
Ya lo tengo Crea una nueva Item vendido o línea de venta O como lo
queramos llamar Se lo dice a la venta Porque claro el que está manejando
La colección de los productos Vendidos es venta No lo está haciendo éste
Eso es una responsabilidad De venta así que El controlador se lo pide a
venta Y le metes La cantidad que me la ha dicho el actor Y El precio, la
descripción Es decir especificación del producto Que he encontrado En el
catálogo de precios De los productos Se lo pasa éste Pues éste crea un
elemento Fijaos en este mecanismo Se crea un elemento Y se añade A la
colección que estaba vacía Si estamos en el cuarto Pues no estaba vacía
Pero igualmente se crea uno Con los datos que le estamos dando El precio La
cantidad Y se añade a La colección Que se va a quedar Como componente De
la venta Y eso es Elemento del registro de ventas Así que cuando termine Y
lo quiera recoger La tienda Lo va a tener todo ahí Bueno pues éste mismo
En colaboración Bueno Aquí en la colaboración Estoy poniendo de manera
explícita Que pasa si no lo encuentra En el elemento Vamos a ir por partes
En el elemento Digamos que está en memoria En la colección que está en
la memoria Se recibe En el controlador Se recibe la invocación De agregar
Artículo Y le doy cuál es el Identificador o qué tipo de artículo De
producto es Y la cantidad de producto que compro Así que lo primero Es ir
al catálogo de productos El catálogo de productos Lo que hace es Acceder
a la estructura Del multiobjeto y buscar Ese elemento Si lo encuentra Pues
es EP y devuelve EP al registro de ventas Ahora Si Esto es 1.1 Fijaos 1.2
si no lo encuentra Si no está aquí Entonces Lo busca En el adaptador
Adaptador de productos locales Va a mirar En el fichero Entonces A través
del Fichero 1.2 1.2.1 Lo que hace es Buscar en el fichero indexado Por
clave de Objetos serializados Lo busca Si no lo encuentra Pues entonces Lo
busca en el Servicio El adaptador De base de datos de producto Y a través
de la fachada Accede A la base de datos Obtiene ese elemento Y volvemos
para arriba Y al final Terminamos en el mismo sitio Si en lugar de una base
de datos Fuera un servicio web Pues entonces En vez de ir por aquí
Tendría que ir por aquí Porque tendríamos un adaptador Del servicio Web
de productos Que busca en un servicio web En lugar de una base de datos
¿Veis? Y todo son especializaciones del adaptador De la interfaz adaptador
de producto Así que si no lo encuentra En la memoria Pues busca En el
exterior O en el fichero local Si lo hemos implementado En cualquiera De
esos casos Digamos que esto No forma parte De lo que aparece en el libro
Porque está ilustrando precisamente Cómo se implementa todo este
mecanismo Con una caché De manera que efectivamente Es que es absurdo
pensar Que si tenemos 50.000 productos Vamos a guardarlos todos aquí en
memoria No puede ser así Y además no es razonable Pero digamos Como
estamos Implementando el funcionamiento simplificado De éxito, de la
línea de éxito Lo que hace es buscar el elemento aquí Y una vez que lo
tiene Pues se lo pasa A venta para que cree Un elemento LV Y una vez que lo
tenga 2.1 pues Lo agrega 2.2 Al conjunto LVS Que hemos llamado Que es otra
colección Y así se terminaría la segunda operación La tercera
operación Sería que ha finalizado La introducción de objetos Con lo cual
Se calcularía El total Ojo, mirad bien En el libro El diagrama Los
diagramas de interacción Los de secuencia, etc. Porque en ningún punto
pone El cómo se representa La dinámica del funcionamiento Es decir, el
diseño detallado Dinámico Del funcionamiento Del coste total Calcular el
total Aunque es una función Pero si os fijáis en el código No hay
ningún Objeto de tipo dinero Que represente El total de la venta Ni es una
Información Que se pase como objeto A través de la presentación Afuera
Ni se está manejando Ese objeto total De la venta De la clase dinero Se
está manejando Interiormente en todo lo que estamos modelando La razón Es
que en estos diagramas Los cálculos Y los Algoritmos No se representan Con
ninguna facilidad En este tipo De diagramas UML no puede Representar Un
APEC Un ejemplo de trabajo Como en todos estos Hay que representar el
diseño Con este tipo de diagramas Donde resulta que Lo fundamental eran
Los cálculos que había que hacer Para calcular La propagación De una
enfermedad entre los animales De una explotación ganadera Todos esos
cálculos eran muy difíciles de representar Tanto conceptualmente en el
modelo de dominio Como luego en los diagramas de secuencia Y la razón
vuelve a ser la misma Los cálculos Y el funcionamiento De los algoritmos
No está representándose Aquí Lo que aquí se está representando en el
funcionamiento Son las transferencias De información Y las invocaciones
Para realizar determinadas Operaciones o funciones Cómo se calculan esos
resultados Es difícil De representarlo En este tipo de diagramas El
siguiente paso Que sería El de la representación Pero ya es una
representación estática Sería Lo del diagrama De clases de diseño Donde
se representan Los objetos que estamos manejando Si hubiera necesidad De
representar esto Pues efectivamente Habría que poner Una relación Con el
adaptador de productos Adaptador de productos Y si hubiera alguna Que es
del tipo Adaptador Y adaptador de productos Accedería a lo mejor A la
fachada Es decir Si hubiera alguna El funcionamiento pasada Por el uso de
este servicio De productos Y el acceso al servicio externo Que accede Al
almacén general Pues habría que representarlo aquí Porque se están
invocando Métodos Correspondientes A esta clase En fin, todas las que Se
utilizarán Y tendríamos estas relaciones Como en venta Pues tendríamos
la relación Con el adaptador del calculador de impuestos Que es de tipo
calculador de impuestos Y accedería A lo que fuera Entonces tendríamos
más relaciones Pero si no Estas son las clases ¿Veis? Que casi todos Se
corresponden Precisamente con Con las que aparecen En el modelo de dominio
Pero aquí, ya la relación Es un utilizado por Busca en Se asocia con En
fin, son Relaciones que sí que pueden hacer Referencia a estas acciones De
los Los métodos De estas clases Esto ya son Objetos código ¿Que
coinciden con los objetos conceptuales Del modelo de dominio? Sí Pero hay
otros que para que esto funcione Es posible Que haya que implementar Y esos
son los objetos puramente software Que llamo En muchos casos, y el libro
también Los llama así Fijaos que En el caso del libro Y esto es un primer
Diagrama de clases El pago Asume que es una pago En efectivo Y que el
único atributo Es una cantidad de dinero En realidad El pago es una
abstracción Y puede ser de distintas modalidades Pago en efectivo, pago
con tarjeta Pago a crédito Con lo cual esto se especifica Se especializa
En el que tenga Que ser y sea Este el pago Al implementarse El que genere
un elemento De tipo por ejemplo tarjeta de crédito Y ya accede al servicio
De autorización de pagos Etcétera, etcétera Esto se complica más Y es
un objeto Que se resuelve Mediante otro tipo de objetos Que son puramente
software Y esto Al hacer pago en metálico Se mantiene aquí esta
Abstracción que es Un pago muy sencillo Que no necesita, no requiere más
Pero si fuera otro tipo de pago Pues habría que implementarlo de otra
manera No sería un objeto único y tan sencillo Pasamos ahora a ver Si
tenéis preguntas Sobre la APEC Aunque ya me he enrollado demasiado Como
debí haber previsto Si tenéis preguntas Sobre todo esto Que he contado
Acaso una pregunta En este diagrama si que ponemos El tipo de, en los
atributos Ponemos el tipo o es que No, no, es verdad En los atributos es un
diagrama De clases de diseño, ¿de acuerdo? Así que hay que poner A ver,
que me entere Yo es que estoy usando para la APEC El Argo ML Y que es un
software que no tiene modelo de dominio Pero si tiene diagrama de clase La
verdad es que me parece un poco confuso Ya bueno Digamos Un modelo La
herramienta ASTA Que uso para hacer estos monigotes Tampoco tiene un modelo
De dominio Un diagrama Es un diagrama de clases Que adecuo Quitándole El
compartimiento De métodos Y quitándole Diciéndole que no me ponga Los
tipos De los atributos Y con eso hago el diagrama De modelo de dominio ¿Me
explico? O sea que digamos que Si es posible en Argo ML hacer lo mismo
Decirle, no, es que estas clases Están Están en A ver ¿Qué estaba
diciendo? Estas clases No tienen Ni métodos, ni los atributos Tienen tipo
Si eso se puede decir en Argo ML Perfecto Y si no, pues no sé, buscarse la
vida Para no ponerle los tipos O tampoco ponerle los métodos O no ponerle
ningún método El problema que tiene Como pasa con esta herramienta Es que
si Argo hace algo En ese diagrama Y luego me voy a otro Y Le asigno un tipo
Cambio alguno de los Atributos o le asigno métodos Me aparecen otra vez en
el primero Entonces me lo fastidian ¿Me explico? Entonces tendría que
cambiar de nombre A todos los objetos Ir duplicando los objetos O las
clases Para en cada uno ponerlo de una manera Con lo cual también es
tremendo No puedo hacer Esos ejemplos así Y una cosa, la grabación ¿Se
va a poner en el foro? Sí, sí Voy a poner el enlace Esto está
guardándose En donde guarda Teams Y pues luego Ya llevamos tres horas
Pondré el enlace a la grabación Lo guardaré en Inteka Porque es lo que
uso de repositorio Y el enlace a la grabación La pondré en el foro ¿De
acuerdo? De acuerdo ¿Hay alguna pregunta más? ¿Alguna cuestión, alguna
duda? Sobre el PUF, la PEC Lo que he dicho Ya digo Insisto en mi
recomendación De mirar Los vídeos Los videotutoriales Los manuales Lo que
estoy explicando Y diciendo en los foros Últimamente lo que he hecho ha
sido Suscribir a todos los alumnos En el foro de tutoría Para que les
lleguen los mensajes Si quieren verlos Verán He abierto En el de la PEC No
lo he suscrito a todo el mundo Porque como no todo el mundo Tiene por qué
hacer la PEC Pues no lo he ampliado Pero en el del PUF En el de
preparación del examen Digamos, del trabajo final Y en el de la tutoría
intercampus Eso lo he ampliado a todos los estudiantes Y mi recomendación
es que se miren los foros Y las explicaciones que doy ahí Si alguien me
manda Una solicitud de una duda Pues en la medida de que no sea
Absolutamente personal Lo que voy a hacer Es trasladarla al foro Para lo
que explico Explicarlo a todo el mundo Porque más o menos las dudas Pues
no va a ser una persona única Un estudiante único El que tenga esa duda,
o similar ¿De acuerdo? De acuerdo Bueno pues Pues Voy a Parar la
grabación lo primero Gracias a los que habéis asistido