Hacia una síntesis de diseño a partir de entender Modelado de Software
•
0 recomendaciones•212 vistas
El documento presenta una discusión sobre qué es modelar con software. Propone que el software es un modelo computable de un dominio de problemas de la realidad. Un buen modelo implica organizar el software según la organización del dominio de problemas. También explica que modelar con software implica un proceso de observación, proyección, reflexión y aprendizaje a través del tiempo.
Recomendados
Recomendados
Más contenido relacionado
Similar a Hacia una síntesis de diseño a partir de entender Modelado de Software
Similar a Hacia una síntesis de diseño a partir de entender Modelado de Software (20)
Más de Hernan Wilkinson
Más de Hernan Wilkinson (20)
Hacia una síntesis de diseño a partir de entender Modelado de Software
- 1. Hacia una síntesis de diseño a partir de entender “Qué es Modelar con Software”
- 2. ➢ Socio Fundador de 10Pines ➢ Socio Fundador de FAST ➢ Profesor de FCEyN UBA ➢ Director Adjunto del Depto. de Computación de FCEyN UBA ... ➢ Sobre todo, programador apasionado Hernán Wilkinson
- 6. Si entendiéramos qué es modelar con software, seríamos mucho más felices 😀😀😀
- 9. Software Conjunto de Instrucciones que dado cierto input genera cierto output
- 10. Software Si Software es un “Conjunto de Instrucciones” … ¿Qué es “buen software”? ¿Cómo organizamos el “software”?
- 11. Software (Conocimiento expresado en un) Modelo Computable de un Dominio de Problema de la Realidad
- 12. Software Si Software es un “Modelo” … ¿Qué es “buen software”? ¿Cómo organizamos el “Software”? (rails way vs. modelo way)
- 13. Software “Buen Software” == “Buen Modelo” Lo debemos organizar según la organización del Dominio de Problema
- 14. Realidad
- 15. R
- 18. Modelo
- 19. R Arbitrario - Lenguaje Natural - Ambiguo Contextual Representación ¿Para qué modelamos? ¿En qué lenguaje modelamos? ¿Qué tipo de modelos hacemos?
- 22. Software Lenguaje de Programación → Formal Ejecutable → El tiempo transcurre El modelo está expresado en el código fuente, no en diagramas
- 23. Característica fundamental: Paso del Tiempo en el Modelo
- 25. t 0 t n Es Dinámico - El tiempo transcurre . . . . . .
- 26. Software Aquello que representa el modelo cambia Plano de Arquitectura = Una casa Software = Qué es una casa
- 27. ¿Cómo Desarrollamos Software? ¿Cómo “creamos” un Modelo?
- 29. Observamos
- 35. Observamos Proyectamos Reflexionamos Aprendemos Lenguaje Natural (idioma) Lenguaje Formal (leng. de Prog.) Proceso de Aprendizaje a través de Formalización de Conocimiento
- 36. Característica fundamental: Paso del Tiempo en el Desarrollo
- 37. Diseñamos Para Entender t 0 t n Paso del Tiempo y Aprendizaje
- 38. Transmisión de Conocimiento t 0 t n . . . . . . . . . . . . . . . . . . . . . . . . . . . .
- 39. Software Es fundamental que nuestros modelos “nos enseñen”
- 42. Modelar es una actividad “creativa”, no repetitiva
- 43. Estimar es difícil porque no estimamos Cómo Construir sino Cómo Diseñar
- 44. Por ser un proceso de aprendizaje, trabajar con hechos concretos y el feedback inmediato es fundamental Por esto TDD es fundamental
- 45. Es un trabajo de mejora constante Nunca lo primero que hacemos “está bien” ¡El cambio más importante es el que refleja cómo entendemos el dominio!
- 48. Modelar un Semáforo luzRoja o señalDeDetención H1: Siempre modelar el rol del ente físico, no el ente físico
- 49. ¿Semáforo?
- 50. ¿Qué podemos decir de Representar?
- 51. H2: Por cada ente de la realidad debe haber un objeto que lo represente
- 52. ¿Se cumple siempre? ¿Cómo representamos Feb/2018, un mes de un año, en Ruby/Python/JavaScript/C++/etc?
- 54. Problemas: ● Soluciones ad-hoc ● Reinvención de la “rueda pinchada” ● Software difícil de entender ● Código repetido ● Errores inesperados
- 55. Java 1.8
- 57. Interludio Los calendarios son un excelente ejemplo de modelado y uso de metáforas
- 59. Un muy buen ejemplo de un muy mal modelo es java.util.Calendar
- 61. ¿Cómo modelo una LlamadaTelefónica?
- 71. Problemas: ● El modelo no nos enseña cómo usarlo ● El modelo no nos enseña cómo evoluciona ● Errores de null por todos lados ● etc etc etc
- 72. H3: Un objeto debe ser inmutable si el ente que representa es inmutable H4: Los objeto se debe crear completos H4.1: Tener un único constructor principal El resto deben estar basados en el completo
- 73. ¿Se debería poder crear 31/Feb/2018?
- 74. ¿Se debería poder crear 31/Feb/2018? 03/03/2018
- 75. ¿Se debería poder crear 31/Feb/2018? ¡Excepción!
- 76. ¿Se debería poder crear 31/Feb/2018? ¡Excepción!
- 77. Problemas: ● Modelos inconsistentes ● Errores inadvertidos ● ¡Modelos que no nos enseñan! ● etc etc etc
- 78. H5: Solo crear objetos válidos H6: Representar entes inválidos o en proceso de estar completados con sus objetos correspondientes
- 79. ¿Qué sucede con esta relación?
- 80. ¿Qué sucede con esta relación?
- 82. Complejidad = C. Esencial + C. Accidental
- 83. ¿Qué sucede con esta relación?
- 84. ¿Qué sucede con esta relación?
- 85. Problemas: ● ¡Pérdida de Información! ● Modelos que no nos enseñan ● Nosotros tenemos que “deducir” ● etc etc etc
- 94. https://www.youtube.com/watch?v=8cgmdaKwRvU Design Principles Behind Patagonia Barcelona - Esug 2010
- 95. H7: Modelar con Medidas, no solo números H8: No usar null
- 97. No vamos a encontrar la solución en nuestra profesión
- 98. aunque … 👏👏 👏
- 99. H9: Modelar “conjuntos de objetos” H10: Modelar la arquitectura del sistema en el sistema mismo
- 101. Conclusiones
- 102. ● Entender qué significa modelar con Software simplifica mucho los problemas que tenemos en la actualidad ● Nos da un marco conceptual sobre el cual pensar nuestros procesos y diseños
- 103. De ahora en adelante, cada vez que te enfrentes a un problema, pensalo en el marco de “qué es modelar con software”
- 107. Muchas gracias
- 108. info@10pines.com 10pines.com +54 (011) 6091-3125 / 4893-2057 Av. Leandro N. Alem 896 6° - Bs. As. - Argentina @10pines Creative Software Development