¿Qué significa el diseño del programa en la programación?

En mi opinión, una excelente analogía es construir una casa, como si hablaras de construir un programa. Los carpinteros, los plomeros y los electricistas no solo aparecen el mismo día, sino que los carpinteros juntan algunas tablas, los plomeros pegan trozos de tubería y los electricistas ensartan los cables en todas partes, todo de una manera totalmente descoordinada y nadie está realmente muy descoordinado. seguro de cómo debe verse la casa. Desafortunadamente, esa es la cantidad de programadores que compilan el código, escribiendo combinaciones de líneas aparentemente aleatorias sin un concepto real de cómo van a encajar. El diseño está destinado a solucionar ese problema y evitar gastar una cantidad innecesaria de esfuerzo en el reprocesamiento para corregir errores que nunca deberían haberse cometido en primer lugar.

Con una casa, uno comúnmente tiene un contratista general y un arquitecto trabajando juntos para decidir cosas como cuántos niveles habrá (¿sí o no en el sótano? ¿Sí o no en el piso de arriba?) ¿Cuántas habitaciones y baños deberían existir y ¿Cómo deberían organizarse entre sí? ¿Qué tipo de electrodomésticos, iluminación, enchufes, etc., y qué tamaño de caja de servicio se necesitará? ¿Qué tal un garaje y, de ser así, cuántos autos tendrá? ¿Qué tipo de características estéticas se incluirán? Muchas de estas cosas serán problemas de requisitos para la funcionalidad, pero muchos aspectos involucran ¿cuál de las muchas implementaciones posibles que decidiremos construir? ¿Cuánto hormigón, madera, tuberías de entrada y salida de flujo para plomería, enchufes eléctricos, interruptores automáticos, etc. se necesitarán? ¿El diseño concebido cumple con los requisitos del código de construcción para la cantidad de tierra que debe dejarse sin cubrir por concreto, seguridad contra incendios, etc.? Una vez que todo ese diseño se haya resuelto y diagramado, se pueden pedir los materiales adecuados y los comercios de construcción respectivos sabrán lo que deben hacer para satisfacer ese diseño, que, a su vez, debe satisfacer los requisitos.

En términos de diseño de software, ¿el programa se ejecuta en una sola computadora o en varias? Si hay varios, ¿hay un servidor junto con varios clientes? ¿Una o más computadoras estarán dedicadas a ejecutar este programa (junto con el sistema operativo subyacente requerido), o este programa se ejecuta junto con otros programas, o estamos hablando de la nube? ¿Qué método de comunicación crees que es más apropiado para que tu programa se comunique con el usuario en el mundo exterior, con hardware, con el sistema operativo y, si tu programa se divide en subsistemas significativos, esos subsistemas entre sí? ¿Cómo planea evitar y, si es necesario, manejar las condiciones de carrera? ¿Cómo planea manejar los problemas de seguridad (proteger datos, detectar intrusiones, pérdida de disco duro debido a problemas de alimentación, activar sistemas de respaldo, manejar entradas defectuosas)? ¿Qué sistema (s) operativo (s) deberían usarse (distribución de Windows ___, ___ de Linux, Apple OS X ___, otros?) ¿Qué lenguaje (s) de programación deberían usarse para qué partes del programa? Si es necesario realizar varias tareas, ¿cuál es la prioridad y la frecuencia de cada tarea? ¿El sistema está controlado por el tiempo, por eventos o por alguna combinación? ¿Cuánta potencia informática necesita (capacidad de CPU, memoria, enlaces de bus)? Esto es solo una pequeña parte de lo que implica el diseño. Las preguntas reales que deben formularse dependen en gran medida del sistema y el programa: un sistema embebido en tiempo real que controla un avión es muy diferente de las macros para una hoja de cálculo Excel que realiza un seguimiento de los ingresos, gastos e inventario de pequeñas tiendas familiares.

Además de responder las preguntas apropiadas, también debe saber por qué tomó las decisiones de diseño que tomó. También debe obtener la aceptación de las personas que establecieron los requisitos de funcionalidad para el software, así como de los programadores que implementarán el diseño.

Significa que tiene la tarea de diseñar los pasos individuales que todo el sistema tiene que hacer para cumplir con la tarea en cuestión.

En lugar de simplemente escribir funciones basadas en lo que otro diseñador ha pensado, usted es el que piensa en lo que otros tienen que escribir.

Entonces en tu caso. ¿Cuán remoto es ese sistema? ¿Cómo identificarías ese sistema remoto? ¿Cómo sabría el sistema remoto que eres tú? ¿Qué pasa si la red del sistema remoto está inactiva? ¿Va a enviar correos electrónicos o sms para obtener ayuda o simplemente encontrará otro sistema remoto?

¿En qué formato están los datos? ¿Qué pasaría si esa información es capturada por alguna competencia? ¿Qué pasa si los datos son incorrectos? ¿Dónde entregará esos datos? ¿Cómo lo guardarás? Si hay muchos datos, ¿cómo sabe qué hay de nuevo? ¿O va a transferir todos los datos cada media hora en su totalidad? ¿Quién necesita esos datos? ¿Cómo sabes que necesitan esos datos? ¿Cómo identificaría a dichos usuarios y cómo evitar que algún hacker robe los datos intermedios? ¿Cómo manejarías las actualizaciones? ¿Reformatea los datos, los combina o recalcula algo? ¿Cuánto tiempo conservarán los datos? ¿Quién pagaría por su servicio? ¿Cuál sería tu competencia? ¿Puedes usar productos de la competencia más fácilmente? ¿El código que está a punto de hacer ya está en el mercado? ¿Hay partes que ya están en el mercado? ¿Podría descargarlos / usarlos, etc.

Básicamente solo significa que lo diseñas primero, antes de que realmente escribas el código. En los primeros días, la costumbre era dibujar un diagrama de flujo, más tarde, la preferencia era psuedocode. Hoy en día, escribimos especificaciones que describen toda la funcionalidad, requisitos, sugerencias de prueba, interfaz de usuario, gráficos jerárquicos (consulte http://ryteway.com/Design/TIM- …), árboles de objetos, clases, entradas, salidas, dependencias externas, etc., etc. Es mucho trabajo pero realmente vale la pena al final. Un equipo con el que trabajé en Microsoft pasaría 6 meses diseñando antes de escribir una sola línea de código. Nunca he oído hablar de errores o quejas de usuarios del código que escribió el equipo.

Es la organización amplia de su código, cómo elige dividirlo.

Aún así, una buena manera de hacerlo es con tarjetas UML, CRC o algunas cajas y líneas

  • ¿Cuáles son las clases principales que usarás?
  • ¿Qué responsabilidades deberían tener?
  • ¿Con qué otras clases colaboran?

Un breve resumen de esto, con viñetas para las responsabilidades clave de cada clase, debería estar bien.

Lo que realmente significa, usando un diagrama de flujo, inglés o imágenes, es analizar el problema y encontrar una solución.

En cuanto a las demostraciones, cada programa es una demostración de cómo diseñar un programa, pero los pasos de diseño no están en el programa, solo el resultado es. Si quieres ver los pasos, eso es parte de la informática. Vea la sección de Programación en Teach Yourself Computer Science. (Si tiene que comenzar a trabajar en él en algún momento de este año, la programación de aprendizaje llevaría demasiado tiempo, así que prescindir de la demostración).

Lectura en diagramas UML, se pueden usar para diseñar la mayoría de las cosas. Me parece que algunos diagramas de flujo simples y diagramas de objetos hacen aproximadamente el 80% del trabajo. El texto suele ser suficiente para describir el resto.

Tenga cuidado con las demostraciones, se puede considerar “externalizar” su proyecto. Que es una forma de plagio. La palabra ‘Diseño’ puede tener un significado diferente, como el de ‘Patrones de diseño’ de GoF. Sin embargo, en su caso, probablemente signifique un bosquejo o un breve resumen de cómo es usted y qué debe hacer.

Un diagrama de flujo es una excelente manera de representar su idea. Una vez que tenga el ‘programa’ en este formulario, puede manipularlo eliminando partes innecesarias, si las hay.

Sin embargo, el mejor consejo es pedirle a la persona que explique su pregunta.

Por el término “diseño de programa” me parece el diseño arquitectónico general del programa de aplicación. Y para crear un diseño arquitectónico de un software, es posible que necesite identificar los patrones de diseño en el software de su aplicación y luego ponerlos en un diagrama (Tipos de diagramas UML con ejemplos para cada tipo de diagramas UML).

Para los patrones de diseño, me encanta este sitio (Huston Design Patterns).