Teoría y fundamentos del diseño

Como ya habíamos hablado en una instancia previa, nosotros estuvimos haciendo el análisis y definimos el problema. Para definir el problema, estuvimos tratándolo desde un alto nivel de abstracción hasta un nivel bajo de abstracción con detalle, tratando de establecer los momentos de verdad que existen entre el aplicativo y el usuario. Todo eso yo he modelado a través de la metodología que dispusimos en el estándar y de esa forma determinamos la necesidad de negocio y la necesidad de usuario y al mismo tiempo establecimos aquellas restricciones que se podían producir, ya lo hemos hablado en cuanto a lo financiero, lo tecnológico, la disponibilidad de equipo y con eso lo que buscamos en la instancia de diseño es encontrar una solución a alguna la aplicación informática que hemos pensado que puede dar respuesta a la problemática es la solución esperada que vamos a codificar eh a probar a desplegar y luego a mantener. Es decir, vamos a construirlo y lo vamos a mantener. En esta instancia es la que el pensamiento lleva a la definición de un esqueleto o un plano de de esta solución que que tiene algunos objetivos. Por un lado, generar una guía que permita la construcción asociada al modelo prescriptivo también que vamos a utilizar, del cual hablamos la clase anterior. Eh, utilizar esto como este esqueleto como base para la administración del proyecto que asociado al modelo de de desarrollo que vamos a a seleccionar nos va a definir los entregables y la oportunidad de entrega. Y por otro lado es un elemento de comunicación permanente de las decisiones que hemos tomado para construir. Vamos a a comunicar estas decisiones con el usuario y vamos a a comunicar estas decisiones hacia adelante en el proceso de construcción de despliegue y en el en la instancia de mantenimiento. Y en el diseño entra en juego la creatividad, esa capacidad que tienen las personas de de inventar, en este caso, de inventar una solución para un problema y a priori inventar un conjunto de soluciones hasta optar por las que uno considera óptima para la necesidad que tiene el cliente y el usuario. Y eso se combina con la experiencia que es expertiz que uno tiene para para poder solucionar problemas buscando en el pasado eh aquellas soluciones exitosas y pudiéndolas trasponer en el tiempo a una nueva realidad, una nueva realidad que es es esta necesidad de la aplicación, modificándola en lo que sea necesario o aplicándola en forma similar a en el pasado. Pero por otro lado, cuando no hay esas situaciones de poder trasponer la la posibilidad de de tener la experiencia, asumir nuevos retos, de asumir esos desafíos que que significan crear una solución a una problemática. Eso evidentemente soportado en la información relevada que que me define por un lado los requerimientos, las necesidades del negocio y de los del cliente y los usuarios y por otro lado la las restricciones, esas restricciones que hablábamos que que eran financieras de software, de tecnología, de disponibilidad, de personal, todo ese tipo de de aspectos que uno tiene que tener en este jugar con todas las cuestiones del problema, ¿no? Y el echar mano a patrones, que que es un es ese esa biblioteca de situaciones exitosas del pasado que nosotros eh utilizamos eh que en realidad reutilizamos, ¿no?, que reciclamos para esta nueva situación. Esto evidentemente soportado en un conjunto de principios, buenas prácticas y estilos constructivos que nos da la profesión, que son esta estas cuestiones que yo digo siempre que de una forma otra del consciente uno lo va pasando al subconsciente. ¿Y qué qué tratamos de lograr con eso? Como una especie de restricción mental que hay que tener en cuenta y que siempre lo tenemos que tener como horizonte. eh un software que sea funcional, un software que vaya hacia la necesidad concreta y por ende que sea de calidad, sí, calidad pensado en términos de del usuario, del cliente, que sea resistente a las al nivel de exigencias que pueda tener el aplicativo. Eso va a surgir del relevami de los relevamientos que realizamos y del análisis. Eh, pero también que permita eso que hablábamos de la escalabilidad de poder ampliar y por lógica el mantenimiento que si en el futuro voy generando parches eh el software resista eh el parche por un tiempo razonable. Y por último, que sea bello, ¿sí? que tenga eh esa belleza, esa cuestión atractiva que evite que se produzca en el momento de verdad inicial entre el usuario, el software, un rechazo, sino que sea agradable acceder. Eso como más o menos decimos en determinados oficios, las buenas artes hecho a partir de las buenas artes. Como ya habíamos hablado en alguna clase anterior, existen un conjunto de principios que va definiendo la profesión y que sin lugar a dudas tienen que estar presentes en en nuestra forma de encarar la resolución de los problemas a través de aplicaciones informáticas. Y en este en este tema de diseño no es la excepción. Y veamos alguno de ellos. Uno de ellos es la rastreabilidad, que es buscar esa trazabilidad entre el diseño y los requisitos como una forma de identificar los fundamentos de la decisión. Y esa redabilidad también va a existir hacia delante de forma de que cada acción que nosotros hagamos en el desarrollo del software tenga su fundamento en una acción, una decisión previa. Eh, por otro lado tenemos a la arquitectura como la definición de de un panorama general completo de lo que va a ser la aplicación, ese paraguas que va a cubrir toda la aplicación, que le va a dar su alcance y va a tener contemplado el objetivo de la de la aplicación. Es esa arquitectura nos va a dar una integridad conceptual de lo que es la aplicación. Eh, y otro tema que habíamos planteado en el en el pasado nos va a permitir enfocar todas las acciones. Por otro lado, eh plantear que tanto las los datos son eh relevantes como las funciones. Uno en general tiende a pensar en una aplicación informática haciendo cosas y leer hacer cosas que en realidad en una aplicación informática es procesar datos en pro de de una salida que es la información. Siempre es así. incluso eh cuando significa generar un movimiento mecánico de de un punto de soldadura en un auto, en una línea de producción de automotores, eh ese evento previo que es la posición donde está el auto y los puntos de de soldadura previa va a ser que exista una información que dispara un movimiento. ese movimiento va a ser ese punto de soldadura en un lugar determinado. Eh, y siempre unos, como decía, uno tiene esa tendencia natural a pensar en funciones, qué es lo que hace la aplicación, pero eh muchas veces las funciones salen como eh condición natural de pensar en los datos. Uno piensa en esos datos de negocio que que le estamos exigiendo a la aplicación informática, que va a ser su salida y piensa en los datos del negocio que va a alimentar al proceso para salir con con esa información que es lo que de hecho es la solución, ¿no? lo que está buscando el el usuario tener tener a a disposición un conjunto de información en un lugar de un lugar determinado y una oportunidad determinada de un proceso. Eh, la identificación de los datos, insisto, ya sea por salida como información o el input de los datos del negocio en entrada, lo que me va a permitir es visualizar también las funciones. Entonces, en este caso, tanto datos como funciones tienen la misma relevancia en su identificación. Y cuando hablamos de datos, también podemos hablar del concepto de clase, ¿sí? que es la identificación, por un lado, el atributo, que tiene mucho más olor al concepto tradicional de datos y, por otro lado, la forma de manipularlos a través de los métodos, que tiene mucho más que ver con el concepto de función y después la interacción entre clases que evidentemente es como como se gestionan las diferentes clases y eso tiene que ver con una funcionalidad esperada. la iteración, la iteración como una idea de repensar y y lograr un refinamiento de del diseño. La medida que uno define algo de un nivel alto de abstracción, va después bajando en el nivel de detalle y va va observando en qué medida esa conceptualización de alto nivel permite eh hacer ese paragua que decíamos, abordar los diferentes elementos de detalle y muchas veces ese detalle nos implica que nosotros tengamos que lograr un refinamiento de la arquitectura más alto nivel. eh el concepto de la facilidad, la simpleza en el modelado, para que se permita entender claramente eh obviamente aquellos que los van a construir, van a construir la aplicación y la y van a lograr el mantenimiento, pero también para ponernos de acuerdo con el usuario en la medida que este diseño puede responder a las necesidades que tiene. el manejo de las interfaces con extremo cuidado. El es muy fácil generar errores a través de interfaces, ya sea interfaz de usuario, interfaz de aplicaciones o de módulos. esa interconexión debe ser extremadamente sencilla, fácil de de gestionar, porque al generar error, si se generan ahí errores, eh la la facilidad con que esos errores se van a ir desplazando en la aplicación eh hace que en principio sea muy difícil probar eh y en otros casos el tema de del mantenimiento se va a complicar. En cuanto a la interfaz de usuario, otra vez ser eh además de ser cuidadoso, como decíamos en el punto previo, tener eh tener muy en cuenta quién lo va a usar, en qué contexto lo va a usar eh y cuáles son las características del perfil del usuario para hacer aquello que sea acorde a sus necesidades, algo que sea adaptable fácilmente al proceso de trabajo. y el trabajo en componentes, dividir el el gran problema en pequeños problemas o en problemas acotados de solución. Sí, esto es el trabajo de de apertura de problemas en sus pequeños problemas, ¿no? Y y lograr componentes que sean independientes, que tengan eh en sí mismo eh un objetivo determinado, un producto o un subproducto dentro del proceso, que entre los diferentes componentes el acoplamiento sea sea mínimo, ¿no? Porque ah si yo tengo un nivel de de acompamiento de acoplamiento muy complejo, con mucho acoplamiento, además en en términos de cantidad, las probabilidades de de de eso que decíamos antes de la propagación de errores es muy muy alta, con lo cual eh se me complica la el la prueba y por ende el mantenimiento futuro. Sí, es cae la facilidad de mantenimiento y de prueba. Y por otro lado, los componentes me permiten trabajar en la administración de de los entregables, ¿sí? Permiten una implementación de tipo evolutiva, que es un poco lo que habíamos hablado en la en la clase anterior respecto de los modelos prescriptivos de desarrollo de software, eh que en general todo tiende a ser incremental, ¿sí? Eh, y por un lado incrementar y por otro lado también evolutivo en en una visión de de futuro, ¿no? Que que permita que permita el diseño tener en cuenta que la aplicación puede ir incrementando en eh volumen, ¿sí?, o también en tipo de funcionalidades que van a ir incorporando ese futuro. Es ese paraguas deber ser comprensivo de lo que vamos a entregar ahora o de todas cuestiones que puedan ser necesarias en el en el negocio y que uno puede empezar a vislumbrar desde ahora. y hablemos un poquito de las buenas prácticas, alguna de las tantas buenas prácticas que tiene profesión respecto de del diseño. Y una de ellas es con manejar distintos niveles de abstracción, eh lograr desde esa arquitectura que ya va a contextualizar a a la aplicación en el marco del negocio. decir, vamos a lograr que esta aplicación esté en el contexto propio de la necesidad de negocio, eh, hasta llegar a a niveles más bajos definiendo esqueleto básico para para actuar en el momento de codificación como una guía, desde un nivel muy alto hasta uno muy bajo que permitirá la la codificación. Y ahí vamos a tener lo que ya habíamos hablado, las distintas vistas, la vista global, la vista de dominio de de los elementos que lo componen y la la vista detallada y esta vista detallada que nos va a llevar a la codificación. Pero al mismo tiempo cuando estamos eh estamos teniendo un diseño distintos niveles de abstracción, vamos a tener que enfocar algunas dimensiones. Por un lado, lo que es la vista eh lógica, ¿sí? que tiene que ver con el problema, los funciones, las perspectivas de usuario, todo, todo lo que es la parte lógica de la aplicación, la vista de de del desarrollo que tiene que ver con especificaciones, estándar, la posibilidad de testear que que va apunta esencialmente a cómo el diseño nos va a ayudar en en el proyecto, cómo va a permitir que el proyecto implemente el proceso, eh las vistas del proceso. Sí, todo lo que son la posibilidad de de tener un ambiente operacional, de lograr los comportamientos y escalabilidad que se pretende de la aplicación. Y una última vista que sí también hay que tener en cuenta porque esto nos va a condicionar la forma de de construir es la topología de del sistema esperado. Es decir, una típica topología tiene que ver con con la distribución geográfica de los distintos nodos. Y este tipo de cuestiones eh desde el momento cero hay que tenerlas en cuenta porque va a condicionar todo lo que yo haga eh hasta el nivel más detallado, que en última instancia el detalle va a ser la codificación, ¿no? Entonces, tenemos una vista a lo que es lo duro de la lógica, otra vista a lo que es la posibilidad de llevar adelante el proyecto, otra vista a lo que es la implementación del proceso y por último la vista a lo que es el el la implementación física. Otro de los de las buenas prácticas tiene que ver con lo que ya hablamos de la modularización, ¿sí? esa forma de vivir el problema eh en pequeños problemas. Es el esquema de división de problemas a partir de de características, ¿sí?, o comportamientos que uno ve en el modelo de requerimiento. ¿Cómo puedo eh los diferentes requerimientos bajo un esquema lógico, algo conceptual? Eh, la idea de esto es poder abordar los diferentes problemas por separado, ¿no? Y por eso es es necesario independencia funcional de cada uno de estos de estos módulos. Que además los módulos tengan en cuenta que uno modulariza asociado al al criterio conceptual del negocio. Es trata de pasar el negocio a la aplicación informática. Es cuando uno ve los módulos de una aplicación eh y empieza a visualizar a la organización dentro de del sistema, el módulo de tesorería, el módulo de presupuesto, el módulo de contabilidad, módulo de recursos humanos, son eh elementos de la realidad de negocio, módulo de venta, módulo de compras trasladado a la aplicación informática, que además eh nos va a permitir ir por un lado desarrollarlo con una mayor facilidad asociado a un a un conjunto de gente de usuarios que tienen que ver eh con esas funcionalidades propias. Sí, es decir, yo voy a buscar todo lo que viene tiene que ver con la el módulo de tesorería en el ámbito de tesorería y entonces hago más fácil la historia, pero por otro lado me va a facilitar la entrega, definir entregables, ¿sí? El eh el módulo de tesorería me permitirá eh transar eh hacer todo lo que es transacción de de cobro y de pago, eh hacer las conciliaciones, emitir los reportes para contabilidad, eh generar los arqueos y tiene una vida propia, independientemente de que se va a asociar con contabilidad, con eh presupuesto de caja diario, con todas las áreas, las áreas eh cuentas corrientes, todas las el resto de las áreas que existen en la organización y que nosotros de alguna forma conceptualmente podemos incluir dentro de la de la aplicación. Por otro lado, hay algunos conceptos asociados a la a la modularización que hay que tener en cuenta. Primero, el costo eh está el costo de descomponer versus el costo de interactuar. Entonces, a medida que yo descompongo el problema en pequeños problemas, el costo de de del desarrollo individual de cada uno se hace más es es mucho más bajo y va aumentando el costo de integrar. Entonces, eh y ese ese costo tiene que ver con el el recurso humano esencialmente definiendo qué hacer, ¿no? Es es cuán complejo lo hice o no a la aplicación. Entonces acá va a haber que hacer un equilibrio entre el costo de de ir desagregando o de descomponer versus el costo de integrar. la interacción que existe eh entre los diferentes módulos hacen que que yo tenga que codificar determinada relación y eso hay que buscar un punto de equilibrio donde no sea eh una modularización excesiva contra una modularización escasa. si es excesiva y voy a tener mucho de interacción y no solo el costo que decía antes de los recursos, sino también la problemática que hablábamos de la de los errores y el costo de no descomponer está asociado a tener problemas muy complejos y me va a afectar el desarrollo de la lógica del módulo. Eh, otros conceptos a tener en cuenta es la cohesión del módulo. La cohesión del módulo tiene que ver con esa fortaleza funcional. Sí, el módulo está preparado para hacer algo determinado, es un su producto propio, que es un subproducto de un proceso y casi no necesita del resto para lograr eso. Entonces, eh es más fácil eh no solo desarrollarlo, sino también poder generar entregables. Y habíamos hablado del acopamiento, ya lo dijimos recién, donde buscamos que esa interconexión sea mínima. Y por otro lado, un concepto muy importante que tiene que ver con la modularización, que en principio tiene que ver con lo que es el desarrollo propiamente dicho y se va a trasladar a después la gestión de usuarios, que es el ocultamiento. El ocultamiento de información. Hay dos tipos de información, la información técnica y la información transaccional o corriente. Eh, claramente ningún otro módulo puede acceder a información de cómo procesa este módulo. Sí, ningún usuario puede acceder a a la información de cómo procesar el módulo. Ningún módulo que no tenga interés directo y concreto puede acceder a la información de un módulo y ningún usuario puede acceder a la información de ese módulo si no tiene interés concreto, si no tiene un derecho definido. En síntesis, como habrán visto, tenemos las dos visiones, la de eh módulos entre ellos, es decir, ningún módulo debería meterse en el procesamiento de otro. Eh, ningún módulo debería ver la información que no le corresponde ver. Ningún usuario debería ver eh aspectos técnicos, ¿no? No tratemos de generar hackers. ni debería haber información que no le corresponde ver por sus derechos de usuario o que en realidad los derechos de usuarios están determinados por su participación dentro de una organización, los derechos propios que tienen como persona que trabaja dentro de una organización. Es decir, el hay que tener siempre en cuenta que eh la información es una cuestión de de poder dentro de las organizaciones, pero la información no es del usuario, sino es de la organización. Sí, hay alguien que tiene que definir qué es lo que puede ver cada uno dentro de la organización. Obviamente lo que puede ver cada uno en una organización está asociado, sin lugar a dudas, a eh su función, a sus tareas específicas. El uso de patrones es claramente una práctica que ya venimos reintegrando, la reutilización, reusabilidad de cuestiones ya desarrolladas en el pasado por los motivos que ya habíamos dado, que tiene que ver con el manejo de los costos y además tener en la mano una situación que ya fue probado probada en la realidad. Entonces es un caso exitoso eh usar modelos de alto a bajo nivel de abstracción como como habíamos dicho antes, pero siempre asociados a a un concepto de refinamiento. Sí, ampliar el detalle, ¿sí? para a medida que voy bajando eh en el en el diseño para lograr una fácil codificación, una posibilidad de que sea fácil la prueba y fácil de mantenimiento, logrando que eh la simpleza permanente, el refinamiento tiende a a la simpleza, tanto para documentar por un lado como para comunicar. es una buena práctica, una visualización, un entendimiento de lo que es eh la arquitectura de negocios. Ustedes vieron que que decía que el que de una forma u otra aplicación va a ir replicando alguna algunos elementos de negocio, ¿sí? es porque se tiene que asociar al negocio. Entonces es es una buena práctica entender las áreas de negocio, los procesos de negocio y las funciones de negocio. Y si yo entiendo eso, eh lo que estoy tratando de entender es cómo la cómo la empresa o la la organización se organiza para eh atender el negocio. entiendo la dinámica del negocio, cómo cómo considera la organización, el negocio, cómo va a evolucionar la organización dentro del negocio, cómo se va a estabilizar la organización en el negocio. ¿Sí? Eh, y acá tenemos lo que son las áreas de de negocio, por ejemplo, ventas, compras, son las áreas propia de mi actividad en el contexto y va a haber áreas de negocio propiamente dichas que son el front office, la exposición que que la organización va a tener frente a sus clientes, un área de va a haber áreas de negocio de soporte, por ejemplo, logística, que es un backoffice, que no tiene directa directa eh relación con los los clientes de de de una de una firma, pero que ayudan a a que lo que es la el punto de contacto o el momento de verdad de la organización frente a aquel que es el cliente eh puede llevarse adelante. Y por otro lado, áreas de servicios generales o esas áreas de soporte como contabilidad, recursos humanos. Sí, ahí yo entendí eh que hay ventas, que hay compras, pero ya entendí que hay ventas y compras o que todo lo que uno pueda entender como áreas propias de negocio, insisto, las que son de contacto con el cliente, las que ayudan o las que que hacen de soporte. Y vamos a identificar ahí los procesos de negocio. Y el proceso es cómo se desarrolla es esa eh la actividad de la organización en el área de negocio. Un proceso que empieza y finaliza. Hay un comienzo y un final. Hay actividades, hay tareas y que van a generar un producto o un servicio. Sí. Eh, el todos esos procesos. Sí. Sí. se van a construir con cosas que se hacen con las funciones de negocio. Sí. Y ahí aparecen las funciones de negocio, porque yo en realidad eh puedo hacer venta minorista, pero venta minorista es simplemente un concepto de proceso. ¿Y cómo hago las cosas del proceso? a través de funciones de negocio. Sí, esas funciones, esos servicios internos que hacen que yo pueda hacer que el proceso haga cosas, que el proceso llega llegue al producto, el servicio que estoy tratando de hacer, un producto que puede ser hacia el cliente o un producto interno. Esto para para esto yo tengo que entender cómo funciona la organización, porque en realidad cuando ya estoy en tesorería, yo ya estoy pensando la función de negocio. Sí. Y para eso necesito entender los planes, los organigramas, los manuales y cada una de esas funciones, ¿sí? incluyen determinadas actividades. Y con esta función de negocios yo ya puedo ir pensando en los módulos que pueda tener el sistema. ¿Sí? A ver, esto es pensar en qué áreas de negocio se maneja la empresa, pensar esas áreas de negocio, qué procesos tienen y pensar esos procesos de negocio, qué funciones tienen para poder llevarlos adelante. Y esas funciones de negocio me pueden dirigir a mí el eh la identificación de módulos. Incluso si yo pienso en proceso de negocio, eh le puedo dar una herramienta al usuario o al cliente para que defina las prioridades, cuáles son los procesos de negocio que a él le interesa que se desarrollen primero y cuáles después. Por ejemplo, yo puedo tener un área de negocio que es ventas, ¿sí? un proceso de negocio que es venta minorista, que va desde donde comienza hasta donde finaliza y algunas funciones de negocio como puede ser administración de de cliente, servicios al cliente, administración de orden de clientes. Sí, todo eso son algunos ejemplos. Si tomamos otros ejemplos, yo puedo tener áreas de negocio en un banco que que puede ser a nivel geográfico separado entre matriz y sucursal, a nivel a otro nivel que es secundario más allá de del geográfico, que es banca comercial, banca mayorista, eh gestión de activos y seguros, banca privada. Eso eso son áreas de negocio. Y de ahí voy identificando cada uno de los procesos que tiene la organización y dentro de cada uno de esos procesos, ¿cuáles son las funciones? Y hay funciones que pueden actuar para distintos eh para distintos procesos, con lo cual es interesante mapear el los procesos de negocio con sus funciones para ver cuándo impacta una función en cada uno de los procesos, ¿no? algunas funciones de negocios, venta, mercadotecnia, finanzas, contabilidad, producción, operaciones, el ingreso de los productos, recursos humanos, eh asuntos jurídicos, eh servicio de postventa, infraestructura, planeación, gerenciamiento, todas esas funciones que uno hace para que el proceso de negocio tenga vida y para que ese proceso de negocio actúe en las áreas de negocio. que tiene eh que tiene la organización. Podemos incluso dividir los procesos de negocio en tres. Los esenciales o primarios, que son los más importantes, los que están en contacto con el cliente, los que aporta valor al cliente y son fundamentales. Es primera línea de combate, diríamos, eh, que muchas veces son los que se priorizan. Si estamos muchas veces en eh eh modelos ágiles, esos esos procesos de negocio siempre están en primera en primera línea, ¿no? Son los más relevantes para para aplicar las horas hombre. Eh, a veces pasan más allá de los límites de la empresa porque yo puedo lograr algún tipo de relación con con mis clientes a través de de algún soporte electrónico y yo tengo que desarrollar la forma de interconectar de interconectar con él. Y bueno, tiene una la visión eh típica de la cadena de valor que está generando eh la organización, es el valor que estamos produciendo y es el objetivo central de la de la organización. Después tenemos otros que son de soporte y apoyo, que si bien están formalmente establecidos, no son los que van eh en primera línea hacia el cliente, sino que apoyan a los primarios, no tienen contacto con el cliente. Sí. No, para el cliente no no se visualiza eh se visualiza el valor, no no tiene un valor directo. Yo estoy hablando de de de todo lo que tiene que ver con con marketing, lo que tiene que ver con algún soporte al al proceso de ventas, eso para el cliente no no tiene valor, no tiene un valor directo, pero sí está soportando el el proceso el proceso de negocio de contacto con el cliente, la venta minorista, la venta mayorista, la venta por elearning. Eh, y después tenemos por otro lado los administrativos o de gestión, ¿sí?, que buscan eh cómo eficientizamos el uso de los recursos, cómo logramos la eficacia, permite monitorear, medir, controlar, no no no tiene valor hacia el cliente, tiene valor hacia la organización. Sí, es eh coordina la las actividades, es eh son esos procesos internos que que no impactan hacia afuera, que lo que producen es para darle soporte a los otros. Eh, en los primarios uno ve eh más directo el producto asociado al cliente. Estos son productos producción interna, ¿sí? Son proveedores de de productos y servicios internos. Entonces, uno de los procesos de negocio los puede ir separando así si le interesa, cosa de de saber de poder ir tipificándolos de alguna forma, ir separándose, separándolos y y de hecho no olvidándoselos. Este es un una buena forma de empezar a entender el gran problema. Al final de la presentación anterior hablaba de criterio de buen diseño y cuando hablamos de criterio de buen diseño hablamos de desista económico que no no tiene complejidades, solo tiene lo necesario, se optó por la reutilización. Eh, es visible ese diseño, es visible, permite comunicar las decisiones, es fácil de entender, es eh permite el espaciamiento de de los componentes del del software, sí, la separar en paquetes, paquetes que como habíamos hablado pueden estar derivados del negocio y esos paquetes desde ser entregables o incluso ser aplicaciones separadas. eh contempla una simetría que como un balance eh una consistencia conceptual entre los diferentes niveles de detalle, ¿sí? Desde más alto al más bajo. Eh, se advierte una cadena de dependencia entre los niveles de de abstracción. Cuando uno va de, por ejemplo, de abajo hacia arriba, puede visualizar que un módulo tiene relación directa con el ese módulo que lo ese esa arquitectura más que módulo, esa arquitectura que que lo contiene, permite esa cuestión del paraguas que involucra, que habíamos hablado, ¿no?, que involucra a todo lo que hay adentro. Sí. Y hay una clara segregación de de las interfaces que que se visualizan como debidamente separadas, asociadas con aquello que tiene que ser asociado, ¿no? Que que le da cohesión al método de generación de interfaz de especialmente de usuario, ¿sí? que hay interfaces de usuario asociadas a aquello que necesita la interfaz de usuario. Es este tipo de de cuestiones de criterio del buen diseño, hay que tenerlas muy en cuenta. Y vayamos a un poco a lo que habíamos visto en la la filmina anterior sobre la arquitectura de negocio. de de una forma el concepto de negocio que nosotros interpretamos nos va a determinar las áreas de negocio y a partir de las áreas de negocio vamos a poder identificar los procesos de negocio y con esos procesos de negocio vamos a poder abrirlo en las funciones de negocio que hacen que que el proceso funcione, que el proceso tenga vida. Eh, y eso, esa función de negocio me la va a estar dando el modelo de organización, ¿sí? cómo la entidad se conceptualiza frente al negocio para para enfrentar el negocio. Y a partir de ello, nosotros vamos a tener eh la arquitectura, que es vamos a tener una arquitectura de carácter eh de alto nivel global o general, pero vamos a ir bajando niveles de extracción. Y acá vamos a tener desde los modelos lógicos, ¿sí? que me permite tener la arquitectura funcional, lo que es aplicación con el estilo arquitectónico que de lo que vamos a hablar un poquito más adelante. Vamos a tener el modelo de datos o clases y la arquitectura de datos o clases. Vamos a tener el modelo de usuarios de de tratamiento de usuarios, donde tenemos las interfaces de usuarios, la forma como eh se manipula la entrada y salida de datos. el modélico, modelo técnico de desarrollo, que acá estamos hablando del módulo hacia adentro con con los programas, todos los lineamientos de de trabajo en el programa en dónde se va a manejar la la lógica más fuerte y dura del negocio. Con esto, con esto nosotros tenemos todo lo necesario para mapear el negocio, mapear a la organización y llegar al mapeo de eh la aplicación que vamos a a desarrollar, que ese mapeo de hecho va a ser el diseño. Y acá tenemos un una gráfica bastante interesante, cómo a partir de los modelos de análisis nosotros podemos llegar a a trabajar en los diferentes niveles de abstracción de diseño. Sí, si si tenemos, por ejemplo, los modelos de escenario como el caso de de uso, el diagrama de actividad, los diagramas de carril, de canal, eh nosotros podemos trabajar en la eh como input para eh definir el diseño a nivel interfaz o componente. Si por otro lado también tenemos eh los de comportamiento como los diagramas de estado de secuencia, también podemos trabajar a ese nivel, a un nivel bastante bajo. Eh, cuando hablamos de diagramas de de clase, como el diagrama de clase, los modelos CRC o los diagramas de colaboración, nosotros podemos trabajar en en la parte más arriba de lo que es el diseño, ¿no? Más alto nivel, ¿sí? definiendo la arquitectura de de clases en este caso o eh y la arquitectura funcional. Y por otro lado, los diagramas de flujo como los DFD, de flujo de control o los narrativos que podemos hacer de los flujos nos van a alimentar para los diferentes niveles, porque los diagramas de flujo eh van a trabajar desde un contexto hasta diagramas de diferentes de diferentes niveles y ahí nos va a dar información para la arquitectura de datos, la arquitectura funcional, algunas cuestiones para interfaz y algunas para componentes más por el lado de los diagramas de flujos con narrativos que permitan permitan identificar los momentos de verdad. Eh, fíjense como a partir de de uno tener eh identificado los modelos de análisis, uno va a poder identificar el nivel de de detalle que tiene para hacer el el diseño, ¿no? aquellos que me trabajan un detalle menor, es decir, con más alto nivel de abstracción, me sirven para las arquitecturas funcionales y de datos o clases. Y aquellos que tienen más el momento de verdad eh con el usuario me sirven para trabajar a nivel interfaz y a nivel componente. Si estamos a nivel de arquitectura de datos o de clases, vamos a trabajar con herramientas de un nivel de abstracción alto para hacer la cobertura todo lo que viene más abajo, ¿no? En realidad es el basamiento. El esquema de de pirámide que pusimos es el el basamiento. En el nivel de detalle va a ser más abajo, ¿no? Eh, y vamos a tener los diagramas de clase. Acá vamos a pasar a estabilizar el diagrama de clase desde la el análisis a lo que nosotros entendemos como diseño. En algún punto nosotros vamos a hablar de de lo que es el modelado en orientación a objeto y vemos como hay una transición bastante difusa entre lo que es eh el análisis y el diseño, porque estamos utilizando el mismo tipo de herramienta. Y en para datos podemos trabajar con herramientas como diagrama entidad relación, incluso todo eso acompañado por un refinamiento del dato que nos da el diccionario de datos. Eh, ya vamos a entrar un poquito más en detalle, pero es es una una instancia de identificar más acabadamente lo que va a ser eh los datos y los metadatos que va a utilizar la organización en su software, ¿no? En realidad del software de la organización. Y cuando estamos hablando de arquitectura funcional, eh nosotros ya tenemos con esto lo que es el marco conceptual de la aplicación, cómo va a responder al negocio la aplicación, eh cómo cómo se va a definir el alcance de la aplicación a partir de un conjunto de módulos, la coexistencia, la coordinación de esos módulos, la interconexión, son como decisiones de construcción fuerte. fuertes porque es la que me define el plano el plano general de lo que va a ser la aplicación, cómo las funcionalidades van a interactuar con lo con los datos o las clases. Y si hablamos de diseño estructurado, nosotros vamos a a poder trabajar con diagramas de contexto. Ya ya el tema lo vamos a ver un poco más en detalle, pero una cosa va a ser el diagrama de contexto donde uno ve la aplicación en su ámbito de vida de análisis y otra cosa va a ser el diagrama de contexto de la aplicación propiamente dicha, diseñada, porque en el caso de análisis, nosotros vamos a hacer ese diagrama del sistema y en este caso de la aplicación. Eso ya lo vamos a avanzar un poquito más adelante. Y en ese diagrama de contextos podemos identificar los sistemas eh superiores, los controladores de la aplicación que estamos desarrollando, los controlados que por esta aplicación, otros sistemas que que son pares, que alimentan a la aplicación o que reciben una alimentación de de esta aplicación, los usuarios, los dispositivos que se asocian que que dan impulso al funcionamiento de la aplicación, podemos tener después un un análisis de mapeos eh sobre los DFD de análisis, identificando aquellos que son de transformación, donde uno puede visualizar lo los eh nodos, las burbujas, eso insisto, lo vamos a ver más adelante, pero las burbujas como entrada, proceso, salida o transacciones que me permite visualizar eh dónde hay determinados nodos que me me generan líneas de de transformación. Sí, como que me generan de una decisión de apertura de caminos y eso lo puedo ir traduciendo después eh en una estructura jerárquica de módulos dentro de de lo que es mi mi mapeo de lo que va a ser el diseño de la la aplicación. Y si voy a una orientación eh orientada objetos, una un diseño orientado objeto y ya voy a tener un modelado de de clases que va desde la transición del análisis a lo que es el diseño. En un caso yo planteo el dominio del problema, en este caso yo voy a aplicar el dominio de la solución, ¿sí? donde voy a tener algunas clases de tipo fronteras que son las que se vinculan con el usuario, otras otras que son van a ser controladores, esas clases que me permitirá la coexistencia de de las distintas clases, cómo interactúan, eh cómo se crean, cómo se actualizan, cómo se instan, cómo se se vinculan la comunicación de objeto, cómo se validan datos, las comunicaciones. son son diferentes tipos de clase que eso lo vamos a ir viendo un poco más en detalle más adelante, pero que que yo los tengo que tener en un mapeo que que me va a permitir eh poder ir ir bajando en el nivel de diseño hasta llegar a los componentes, teniendo ya sabido cuáles son las clases con las que voy a con las que voy a trabajar. Sí. Eh, y incluso voy a tener algún tipo de de clase de infraestructura que tiene que ver con con las clases de interfaz, la eh las clases que que me permiten tener la persistencia de datos, las clases de sistema que me permite operar el sistema y generar comunicaciones con un entorno de computación, un mundo exterior, diferentes tipos de clase en función de de lo que va a ser la aplicación propiamente dicho. Es decir, por un lado las que están asociadas directamente al negocio y por otro lado, las que van a hacer que la aplicación pueda funcionar en el ámbito de informático en el que estoy estoy trabajando. Y si recuerdan algunas presentaciones anteriores, habíamos puesto en una pirámide al diseño soportado en los principios, en las buenas prácticas y en los estilos constructivos. Y acá vemos los estilos constructivos y tenemos eh cuatro cuatro estilos típicos son los más conocidos, que algunos de ellos son combinables entre sí. Eh, y y vamos a ir de izquierda hacia abajo y hacia la derecha. Sí. Y el primero a la izquierda es este es muy muy difundido. Ustedes lo seguramente lo conocen. Es un estilo basado en datos. Sí. donde eh la idea es eh trabajar sobre ABM en los datos a partir de cada uno de esos software que están ahí identificados como de cliente, ¿no? Esto es muy típicos en en los sistemas modulares de de grandes organizaciones donde eh cada uno de de esos pequeños modulitos eh van tomando una parte de de negocio y van disparando eh hacia la base de datos, tomando y manipulando el dato y haciéndolo persistir dentro de la base de datos. datos. Si se si ven eh los módulos no se comunican entre ellos. Los módulos se comunican, si es necesario a través de la la base de datos. Insisto, esto lo que tiene la característica es, ¿se acuerdan cuando habíamos hablado del modelo en espiral? Esto es muy típico que se use frente a esto, el modelo espiral donde estamos todo el tiempo agregándole módulos nuevos, funcionalidades nuevas y van disparando contra eh la base de datos. Esto eh este es un estilo de base. En alguno de esos módulos que ustedes ven cliente, uno puede utilizar otro estilo, pero solo enfocado a ese módulo. Sí. y que el resultado sea eh disparar contra la base de datos. Eh, insisto, esto es típico, por ejemplo, a ver, yo recuerdo lo que era el sistema informático María de la Aduana. Eh, su momento era el Sofi de Francia que se trasladó a la Argentina. Y en la primera parte lo único que hacía era gestionar la registración de las despachos de importación y de exportación y la liquidación de de impuestos. Bajo este esquema, después se le agregó lo que era manifiesto, lo que era eh verificación, lo que era garantía, todos como pequeños módulos que iban trabajando y gestionando hacia la base de datos, ¿no? Que iban tirando tirando una actualización de datos sobre la base. incluso eh determinados módulos exigían, por ejemplo, para ser verificado existía la exigía la existencia de un despacho registrado y era la forma la forma de vincularse eh solo a través de la base de datos. Después izquierda abajo tenemos eh un modelo más tradicional, más clásico, ¿sí? El el de llamado retorno o llamado regreso. Es modelo jerárquico donde hay programas principales y subprogramas. Uno invoca eh y controla y el otro eh gestiona y la parte del proceso que que llamaba y devuelve devuelve el control al aquel que que está por encima. Esto es muy típico de de un esquema de menúes. Eh, si ustedes lo ven, es un esquema de árboles que se va desagregando. Eh, en una en un esquema de diseño estructurado. Es muy fácil salir de lo que es un diagrama de flujo de datos en eso que yo les había comentado de de transformación y transacción y llegar a a este modelo. es es incluso eh cuando uno empieza con esto de del desarrollo de software echa mano a este tipo de de modelos que es muy o de estilo más que de estilo conductivo que es muy muy cómodo, pero bueno, eh la magnitud y el avance tecnológico y la complejidad de las aplicaciones hace que este tipo de estilo pueda complejizarse de demasía. eh si la magnitud de la aplicación es es muy grande, ¿no? Después tenemos eh a la derecha y arriba es otro estilo que es el de flujo de datos. Es es el esquema de Workflow eh que trabaja con datos de entradas y transformaciones hasta datos de salida. Esto es muy típico para trabajar con modelos de transacciones que que exigen autorizaciones y aprobaciones. Sí. es todo el es es más o menos como el marco del seguimiento de un expediente. Sí, este es modelo bastante típico workflow. Y por otro lado tenemos el estilo de capas muy usado. El estilo de capas es muy usado en muchas profesiones. Lo que se caracteriza es por trabajar con reglas propias a nivel capa, incluso con la definición de las reglas de interconexión entre las capas. Eh, en el caso nuestro, eh, además es la idea de que eh vas eh siendo subsumido uno respecto del otro entre un punto de partida y un punto de llegada. Si ustedes lo ven acá, el punto de partida, lo que tenemos más y hacia adentro en en estas estas burbujas eh concéntricas es el hardware. Después, fíjense que tenemos todo lo que es gestión de memoria. todo lo que es eh gestión de procesos, gestión de entrada de salida, programa de usuario, interfaz de usuario, es decir, todo las todo lo que necesito para llegar desde el eh desde el hardware hacia la hacia el usuario. Fuera de esto está el usuario. Eh, cada una de esas cuestiones se manejan distinto. Otra otra forma podría ser es en el centro tener los datos más y hacia afuera tener las reglas de negocio hacia afuera las interfaces de usuario, más hacia afuera, la gestión de derecho de usuario, más hacia afuera, el esquema de seguridad y hasta llegar al al usuario, ¿sí? Es decir, y cada uno de esas de de esas capas se gestionan bajo los criterios propios, incluso puedo asignar responsables directos y cada vez que se cambia algo, se cambia bajo esas reglas y uno visualiza en qué medida ese cambio impacta hacia afuera o hacia adentro. Sí. Eh, insisto, es un modelo muy usado eh para esto, para separar conceptualmente lo que uno quiere someter a distintas reglas. en orientación objeto. Esto es típico en cuanto a diseño de interfaz. Eh, fíjense ustedes que nosotros las tenemos establecido con carácter previo al los componentes, ¿no? Al trabajo de diseño a nivel componente, pero tanto las interfaces de aplicaciones como las interfaces de usuarios de alguna forma condicionan lo que son los componentes hacia dentro, ya sea porque esta interfaz eh impulsa el procesamiento de de código eh o porque necesita respuestas de ese código. En realidad, la interfaz es el frontend que tiene el usuario y en un caso de interfaz de usuario u otra aplicación e y va a condicionar la forma en que va a actuar el el componente. Eh, por un lado, el tema de interfaz de aplicaciones es eh uno tiene que definirlas con extremo cuidado porque es la forma de comunicarse con con otras aplicaciones y es eh la forma de no trasladar errores, sino que pueda ser interpretado de una forma correcta. Ahí tenemos los que son los totales de control, total de comprobación, una metodología de control que permita que ya sea por recibir o ya sea por entregar información, podamos interpretarla como corresponde y y validarla. Por otro lado, tenemos eh a nivel interfaz de usuario lo que sería mantener el control de la de la aplicación por medio claramente por medio de la interfaz en manos del usuario. Es decir, no no hacer que haga cosas innecesarias, que esa interfaz le dé cierta flexibilidad en el manejo, que pueda comportarse como experto, es decir, conseguir atajos, que permita manipular objetos y hacerla de una forma eh más integrada a su propio trabajo. Y por otro lado, que no tenga aspectos técnicos que tenga que ver. Hay que ocultar todos aquellos aspectos técnicos que no son necesarios para su trabajo. reducir la carga memoria de de corto plazo, es decir, que no necesite su propia su propia memoria, sino que todo lo que tenga la vista tenga algún significado preestablecido, que le permita el uso de atajos, que que le facilite una selección, que maneje en la interfaz la metáfora del mundo real utilizado utilizando las terminologías, eh las gráficas, incluso las fotos que son del mundo real de la tarea en la que se se ve inmerso eh la interfaz de usuario y por ende la aplicación. que sea consistente esa interfaz con su propia tarea, es decir, que se pueda acoplar fácilmente la tarea y con otras aplicaciones, que no rompa eh un ambiente de metáfora eh propia de otras aplicaciones, salvo que la decisión concreta sea romper con algo, ¿no? Muchas veces que uno quiere generar un cambio y necesita mostrar algo distinto, pero ya terminaría siendo una decisión. En principio, uno debería eh ser consistente con el resto del mundo de aplicaciones con las cuales va a trabajar, eh que maneje eh las respuestas con con cierto criterio para manejar la ansiedad de del usuario. Nosotros sabemos que que el usuario está esperando algo, ¿sí? Y si por ejemplo los tiempos de respuesta son distintos, de alguna forma vaya manejando esa esa ansiedad. Claramente la cuando uno hace un diseño y hay determinados comportamientos esperados, eh va a tratar de que la eh la aplicación mantenga ciertos estándares de respuesta, pero en el caso de que frente a una una respuesta esperada se genera un desvío, de alguna forma tengo que mostrarle eh darle alguna respuesta al usuario de manera que no se sienta que no va a recibir la respuesta. el manejo del error, ¿sí? que que en realidad tengo que dar poner en en manos del usuario todos los elementos que eviten que él eh pueda cometer un error. Eh, por eso el despliegue de datos eh de alguna forma, la la posibilidad de que él pueda hacer una selección, por ejemplo, o frente a un error en carga, el la misma interfaz trabaje para para exhibirle ese error. siempre buscando que esa esa primera línea de lo que es la aplicación, que es la interfaz de usuario, les le permita incorporar lo que realmente quiere. Es es muy relevante, muy relevante tener extremo cuidado en la en la forma que yo estoy generando mensajes, porque la interfaz de usuario genera los mensajes que va a recibir el eh aquel que lo utilice, ya sea el mensaje de pedido como el mensaje de respuesta. y el uso de de una metáfora, ¿no? La la metáfora viene a ser la forma en como uno presenta esta interfaz. Sí, no necesitamos una metáfora que sea acorde al trabajo, acorde al perfil del usuario y acorde a la organización en la que se está moviendo. No tiene sentido cambiar de metáforas eh si no hay una decisión concreta de cambio de metáfora por el simple hecho de que sea eh un tipo de metáfora utilizada en el mercado. No, no, no tiene sentido porque le genera una un nuevo aprendizaje y por otro lado le va cambiando el ambiente de de trabajo. Piensen que la metáfora que utiliza la interfaz de usuario es el ambiente, es es el espacio en donde el usuario se siente contenido. Es es es más o menos como pensar en una oficina con determinadas características. Esa es la interfaz de usuario, el ambiente donde él tiene que desenvolverse en forma cómoda.