Conceptos y vocabulario básicos sobre diseño de software (01)
HTML-код
- Опубликовано: 11 сен 2024
- Definición de diseño de software; módulo; interfaz de un módulo; principio de diseño para el cambio; ítem de cambio; breve descripción del criterio basado en la ocultación de información para definir módulos y sus interfaces.
Tu canal debería tener miles de suscriptores , muy buen contenido . Saludos desde Lima Perú . 👏👏
Gracias pero no creo que haya tanta gente interesada en la ingeniería de software.
Una vez mas lo felicito profe y le agradezco por el contenido, creo que es el unico canal en español con un contenido tan valioso ya que enseña los conceptos fundamentales
Cuando decidí hacer el canal pensé en hacerlo en castellano porque en inglés ya hay muchas cosas y pone en desventaja a los hispanoparlantes. Así que me alegro que te resulte útil.
He estado un poco frustrada aprendiendo framework tras otro y realmente me acaba de aclarar el panorama con relación al diseño de software, este nivel de abstracción que te amplía la mirada y te hacer ver a los lenguajes de programación como herramientas para poder hacer implementaciones bajo cierta directriz que te enfocan en qué problema resolver más allá del cómo hacer la implementación del mismo. Gracias por eso profesor!! Gracias!!
Me alegra que te sirva. Gracias a vos por visitar el canal.
Muy bueno!, por donde recomendas empezar para diseñar un software, ejemplo por el apartado visual, si lo tiene?
No hay una regla general para eso. Si hay interfaz con el usuario empezaría por definir claramente la interfaz de la lógica de negocio de forma tal que se pueda paralelizar el desarrollo de esa lógica y la de presentación ( interfaz de usuario). Luego diseñarla con más detalle las dos capas de forma independiente.
Impecable!
Gracias!
@@MaximilianoCristiaIS Avise profe cuando crea una academia online. Con gusto me inscribiría. Yo curso tecnicatura en programación. pero sobre temas de Arquitectura y diseño nos falta.
@@juanmanuelcontreras4475 en una tecnicatura no te van a enseñar esas cosas pero sí te van a enseñar a programar, que no es poco. Suerte!
interesante canal unico en youtube pls siga subiendo videos
Gracias a vos por visitarlo. Sí, de a poco voy subiendo nuevos vídeos.
Felicitaciones por la pedagogía utilizada.
Gracias por visitar el canal.
Muy buena Clase, ahora voy a ver y redactar los patrones de diseño. Así cuando siga leyendo el libro de Eric Gamma, lo puedo entender más rápido y de mejor manera. ;D :D😎
Me alegra que te sirva. Gracias por visitar el canal.
Valiosísimo canal Maximiliano!
Me surgen algunas dudas. Cuando hablas de que cada módulo ha de tener una función y además hemos de prever los ítem de cambio y aislarlos por módulos para que no afecten a otros módulos cuando estos cambios se tengan que producir me plantea incógnitas. Qué sería una sola funcionalidad? hasta dónde llegaría? es una sola función o es una agrupación de funcionalidades? y cuando un cambio en principio parecería afectar a varios módulos?
Por ejemplo, si voy a trabajar con objetos referente a personas (clientes de un comercio) y sé que en algún momento dado, además del nombre voy a tener que contemplar también la edad y datos bancarios, ¿cómo tendría que organizar para que estos módulos actuasen tal y como indicas?
Es decir, si quiero sacar aprendizajes de estos datos para ver cómo se comportan tendré un módulo para ello y, además, quiero tratarlos de manera diferente a la hora de ofrecerles descuentos, por lo que tendré otro módulo para los descuentos. Me da la impresión, por un lado, que si tengo un programa un poco complejo tendré casi tantos módulos como clases o incluso funciones y métodos.
Y respecto al item de cambio, cuando incluya la edad y datos bancarios en mi sistema, cómo tendría que hacer para sólo modificar un módulo si quiero tener en cuenta la información en ambas funcionalidades (aprendizaje y descuentos)?
Muchas gracias Maximiliano, me estoy haciendo varios de tus cursos, nos viene de perlas a los que necesitamos aprender por nuestra cuenta.
Respecto a esto:
> Cuando hablas de que cada módulo ha de tener una función y además
> hemos de prever los ítem de cambio y aislarlos por módulos para que no
> afecten a otros módulos cuando estos cambios se tengan que producir me
> plantea incógnitas. Qué sería una sola funcionalidad?
Me refiero a que cada módulo tiene que tener una cierta funcionalidad asignada. No quise decir que en la interfaz del módulo tiene que haber solo un método o función. Qué tan grande o qué tantas cosas hace esa funcionalidad puede variar pero tiene que estar restringida por la cuestión de ocultar un único ítem de cambio en el módulo.
> es una sola función o es una agrupación de funcionalidades?
Es una "funcionalidad" en el sentido general.
> y cuando un cambio en principio parecería afectar a varios módulos?
Esto es normal. La idea es incorporar un cambio grande haciendo modificaciones pequeñas en mucho módulos. Es preferible a tener que reimplementar completamente un módulo complejo y mucho más preferible a tener que reimplementar en gran medida varios módulos.
Respecto a esto:
> Por ejemplo, si voy a trabajar con objetos referente a personas (clientes de
> un comercio) y sé que en algún momento dado, además del nombre voy a
> tener que contemplar también la edad y datos bancarios, ¿cómo tendría
> que organizar para que estos módulos actuasen tal y como indicas?
Es difícil responder esto en tan poco espacio... capaz tendría que hacer un vídeo para explicarlo (pero por un par de meses no voy a poder). El problema en este caso es que un cambio de esa naturaleza afecta la interfaz de uno o más módulos. Cuando un cambio afecta interfaces es un desastre porque impacta por todo el sistema. Entonces hay que prever que la interfaz va a cambiar dejando la interfaz, en cierto modo, abierta. Esto se logra, por ejemplo, recurriendo a una arquitectura del estilo Invocación Implícita (ver este vídeo ruclips.net/video/IsT5o0orRTo/видео.html).
@@MaximilianoCristiaIS Muchísimas Gracias, me veo ese vídeo que indicas y estaré atento cuando publiques más. Un placer y sigo con tus cursos!
Respecto a esto:
> Es decir, si quiero sacar aprendizajes de estos datos para ver cómo se
> comportan tendré un módulo para ello
Si son varios aprendizajes diferentes o variaciones del mismo o diferentes implementaciones, deberías tener un módulo para cada uno (precisamente cada uno representa un ítem de cambio diferente). Para esto seguramente te vendría bien estudiar el patrón de diseño Visitor (Visitante) (podés ver el vídeo ruclips.net/video/3BM5d__kSPk/видео.html).
> además, quiero tratarlos de manera diferente a la hora de ofrecerles
> descuentos, por lo que tendré otro módulo para los descuentos.
Si además tenés descuentos entonces probablemente te sirva combinar con el patrón de diseño Decorator (Decorador; hay varios vídeos en el canal). Cada tipo de descuento debería implementarse en un módulo y deberías hacerlo de forma tal que se puedan combinar y que se apliquen a ciertos clientes y a ciertos no. Para todo esto sirve Decorador. También el estilo de Invocación Implícita es muy útil para estas cosas.
> Me da la impresión, por un lado, que si tengo un programa un poco
> complejo tendré casi tantos módulos como clases o incluso funciones y
Esta forma de diseño efectivamente lleva a diseños donde hay muchos módulos. En general cada módulo corresponde a una clase. Los programadores parecen temerle a tener muchas clases; pareciera que prefieren pocas clases grandes. En mi opinión eso, a la larga (y no tanto), es un error importante. Por otro lado tener muchos módulos puede complicar la comprensión del sistema en su totalidad.
Respecto a esto:
> Y respecto al item de cambio, cuando incluya la edad y datos bancarios en
> mi sistema, cómo tendría que hacer para sólo modificar un módulo si
Como te decía, en general un cambio grande implica realizar muchos cambios pequeños en muchos módulos. Lo mejor es no tener que modificar módulos existentes sino que el cambio se implemente agregando nuevos módulos.
Hola Profesor buenos días en alguna oportunidad le escribí por este medio un mensaje y mi interes en profundizar sobre el tema. La verdad es que estoy interesada en el tema. Soy analista de SIstemas. Hay una posibilidad de tener una comunicación con usted por favor
No te respondí? Respondo siempre. Podes ver el material que uso en mis clases:
www.fceia.unr.edu.ar/is1
www.fceia.unr.edu.ar/is2
Si querés me podés mandar un mail a cristia@cifasis-conicet.gov.ar
@@MaximilianoCristiaIS si si perdón no me exprese correctamente. Ha dado respuesta siempre con generosidad siempre. Pero queria saber si podría enviarle un mail.Gracias por permitirmelo. Un saludo cordial
@@silvinabazan342 dale, escribime
Genial me encantan tus videos!!
Gracias a vos por tu interés en el canal
Excelente explicacion
Gracias!
Buenas tardes.
Saludos, Maximiliano, en el vídeo hablas sobre otros elementos de software que no son módulos.
podrías por favor dar ejemplos concretos sobre estos elementos de software y sus relaciones?. Cuando hablamos de módulos estos pueden implementarse en clases, y los otros elementos de software de que manera se pueden implementar?
saludos desde Ciudad de Piura_Perú
Luis García Cueva
Otros elementos de software que no son módulos pueden ser: procesos, objetos, subrutinas, programas, librerías o bibliotecas, e incluso archivos. Por ejemplo entre procesos puede haber relaciones de sincronización, concurrencia, paralelismo, etc.; entre objetos puede haber relaciones de composición e invocación.
En general los módulos son la unidad básica de construcción así que muchos de los otros elementos se construyen ensamblando módulos pero no es la única forma. Además hay elementos de software que corresponden a visiones estáticas del sistema (módulos, programas, subrutinas) y otros a visiones dinámicas del sistema (procesos, objetos). Es decir que un sistema dado puede ser analizado estática y dinámicamente y para ello conviene analizar los elementos estáticos o los dinámicos; además de analizar la relación entre los estáticos y los dinámicos (por ejemplo, ¿cuáles módulos serán compilados juntos para crear un programa? ¿Cuántos procesos se generarán de ese programa? ¿Esos procesos ejecutarán concurrentemente entre sí?
@@MaximilianoCristiaIS Profesor. ¿Cómo poder definir la función que cumplen los diferentes elementos de software? ¿Necesito saber la responsabildad que estos van a llevar a cabo para poder entender la relación entre ellos?....Gracias por su atención.
@@lourdesvilchez7030 la función de cada módulo se documenta en un documento que se llama guía de módulos. Allí la función se puede describir informalmente o formalmente. Si es informalmente la podés describir en un párrafo hablando de lo que hace el módulo globalmente o la podés describir explicando la función de cada subrutina de la interfaz del módulo. Si es formalmente tenés que usar una notación o método formal como Z, B, statecharts, CSP, etc.
Responsabilidad y función es más o menos lo mismo.
Si describís la función de cada subrutina de la interfaz en general lo más conveniente es hacerlo describiendo las precondiciones y las postcondiciones de cada subrutina.
Acá tenés un apunte de clase que te puede servir:
www.fceia.unr.edu.ar/ingsoft/diseno-a.pdf
Mirá la sección sobre documentación.
Estos cursos es lo básico para la creación de un software???😲
Para mi sí... siempre y cuando tengas conocimientos de programación. Quiero decir, se supone que ya sabés programar y ahora querés aprender algo sobre diseño de software. Si tenés alguna pregunta puntual sobre algo que no entendés, avisame.
@@MaximilianoCristiaIS ya entiendo, si un poco, gracias profe estos vídeos son Importantes para mi lo boya repasar para tener una idea de cuando llegue aquí.
💪
Gracias!
Muchas gracias a vos por tus comentarios.