online - architecture design software

¿Cómo se diseña, se esboza y se planifica una pieza de software complicada? ¿Cuáles son algunos flujos de trabajo o herramientas que se pueden usar para hacerlo? (5)

Los arquitectos planifican un edificio antes de comenzar cualquier trabajo real en él, y lo hacen siguiendo los estándares.

Eso es porque con muchos campos hay el conocimiento exacto de antemano. Lo que está involucrado, qué reglas, qué leyes de la física, qué regulaciones considerar. Es por eso que es posible planear todo hasta el último clavo.

Con el software es muy diferente. Puedes hacer lo que quieras. Puedes alcanzar cualquier cosa y nadie puede decirte que es buena o mala. Porque no hay estándares. Solo opinión subjetiva

Cada vez que he codificado algo, lo hice al iniciar mi editor e improvisar. Métodos de escritura, clases sobre la marcha. Por supuesto, lo pienso de antemano, saco un boceto y escribo mis ideas, hago una pequeña lista de cosas que hacer, etc.

Así es como suele hacerlo. Puede experimentar con algunos marcos, herramientas, arquitecturas antes de comenzar con el proyecto. Por ejemplo, haga algunos proyectos de prueba para aprender lo que necesita para intentar "diseñar" su software futuro.

No quiero opiniones

Cada respuesta aquí va a ser una opinión. Porque no hay estándares a los que recurrir. Experiencia y opinión

Me gustaría algo específico: ¿Gráficos? Mapas? ¿Herramientas? Técnicas? Proceso paso a paso?

Lo que más ha funcionado es:

Involucre a los usuarios desde el principio en su proyecto. Recoge comentarios regulares para ajustar tu curso.
Sea ágil y siga algún tipo de proceso iterativo. Primero, dibuja la interfaz de usuario. Obtenga los comentarios. Luego implementa algunas funcionalidades generales. Obtener comentarios Ajusta tu curso Implementa algunas más características. Y así. Tarde o temprano habrá suficiente carne para ir v.1.

Si necesita absolutamente algunas pautas estrictas, utilice UML (Lenguaje de modelado unificado) para diagramas y gráficos y adopte el RUP (Proceso unificado de Rational) o sus análogos. Puedes seguir Scrum , también hay algo de actividad organizacional.

He estado programando durante un par de años y ahora estoy estudiando informática en la universidad. Cada vez que he codificado algo, lo hice al iniciar mi editor e improvisar. Métodos de escritura, clases sobre la marcha. Por supuesto, lo pienso de antemano, saco un boceto y escribo mis ideas, hago una pequeña lista de cosas que hacer, etc. Esto puede funcionar para escribir pedacitos de código o software simple y relativamente pequeño, pero ¿qué tal ¿complejos?

Cuando quieres crear un software complejo, ¿cómo lo preparas? Los arquitectos planifican un edificio antes de comenzar cualquier trabajo real en él, y lo hacen siguiendo los estándares. Espero que los programadores lo hagan, pero nunca he oído hablar de eso. ¿Cuáles son los métodos, las herramientas y los pasos que se utilizan para hacerlo?

No quiero opiniones

Me gustaría algo específico: ¿Gráficos? Mapas? ¿Herramientas? Técnicas? Proceso paso a paso? ...

En primer lugar, me gusta Mind-Maps para visualizar qué debe hacer esa pieza de software y cuáles son las limitaciones relevantes (tecnología, rendimiento, puntos de integración, etc.). Me gusta usar FreeMind (OSS) para este propósito. Creo que hay una gran diferencia entre simplemente hablar sobre los requisitos y escribirlos, porque el último te obliga a pensar en ellos de manera más precisa. Especialmente si no estás familiarizado con el dominio del problema.

En el momento en que termino con esto, normalmente tengo un buen plano de cosas en mi cabeza y comienzo a programar de inmediato. Si no, empiezo dibujando cosas en papel con una pseudo notación UML. UML es un lenguaje de modelado, específicamente diseñado para este propósito. Define representaciones visuales comunes para clases, métodos, flujos de interacción, etc. No es raro que su diseño cambie un poco a medida que su percepción del problema aumenta al escribir el código. Es importante no dudar en adaptar su diseño cada vez que esto sucede.

Dependiendo del tamaño del problema que se modele, es posible que le resulte útil usar una herramienta UML. Pero generalmente son muy rigurosos y poco flexibles. Especialmente cuando decido cambiar el diseño de mi código, mis diagramas UML se desincronizan muy rápido. Lo que realmente me gusta es el diseñador de clases de Visual Studio, porque funciona al revés, puedo soltar mi código y genera una representación visual (UML simple) de él.

La respuesta estándar hoy en día es bastante simple: dibujar diagramas UML.

En los años, la respuesta debería haber sido: "dibujar diagramas de flujo", "dibujar diagramas de Nassi-Shneiderman", "dibujar diagramas de Warnier / Orr", "dibujar diagramas de flujo de datos" ... etc.

Todas serían buenas respuestas y malas respuestas al mismo tiempo. La realidad es que no existe una única respuesta correcta a la pregunta por la simple razón de que nadie sabe realmente qué es el software en realidad .

Antes de que la gente salte sobre mi garganta, déjame explicarte a qué me refiero.

Cuando un arquitecto crea una impresión azul de un edificio, el producto final es claro: será una estructura física con paredes, puertas, ventanas, etc. Nuestro arquitecto trazará una línea y dirá: "esto es una pared"; dibujará otra línea y dirá: "este es el cable de la antena de TV desde el techo hasta el sótano". Usando algunas convenciones sobre las dimensiones (la escala), los colores y los tipos de líneas, podrá comunicar a los demás lo que se debe construir y cómo encajan las cosas.

Puede haber algunos malentendidos sobre los detalles, pero nadie dudará de que el modelo 2D que están viendo representa realmente un edificio. Incluso si se necesitan diagramas múltiples (por ejemplo, uno por piso) es bastante fácil relacionarlos.

¡Para un sistema de software todavía no estamos en ese nivel! La primera pregunta es "¿cómo modelarás el software"?

Si utiliza el enfoque orientado a objetos, describirá su software como un conjunto de "objetos" pertenecientes a "clases" que están relacionados entre sí (como se describe en el "diagrama de clases"), con un comportamiento determinado (un "estado" diagrama ") y que interactúan de ciertas maneras (como se describe en un conjunto de" diagramas de colaboración ").

No hay un solo diagrama que le muestre todos los aspectos de un sistema de software. Es por eso que UML incluye muchos tipos diferentes de diagramas.

Si está utilizando un enfoque estructurado , describirá su sistema como un conjunto de componentes de procesamiento que transforman su entrada en salidas (un DFD) y como entidades de datos configuradas (como un diagrama ER).

Cualquier diagrama funcionará siempre que su significado sea claro para todas las partes involucradas. De hecho, es común comenzar una sesión de diseño dibujando dos cuadros en la pizarra y una línea entre ellos que dice: "Ok, ese es el navegador que se conecta a nuestro servidor web ...".

El problema radica exactamente en lo que significa cada diagrama.

En realidad, tenemos una buena forma común de representar la parte de datos de un sistema: un diagrama de relación de entidad (o la "parte estática" de un diagrama de clase) se puede traducir directamente a una base de datos en vivo. Atribuyo esto al hecho de que las bases de datos relacionales están bien fundamentadas en el álgebra relacional y, al mismo tiempo, usan conceptos simples que cualquiera puede comprender (tablas, claves externas, unir, ...). Todas las otras representaciones de datos han sido aniquiladas (¡no más bases de datos jerárquicas!).

Lo que nos falta es una visión común y aceptada de los aspectos dinámicos del software; una visión unificadora que sería teóricamente sólida y no difícil de usar.

Eso dicho aquí es mi sugerencia.

Recuerde que el propósito mínimo de una arquitectura es crear una comprensión común del sistema.
Aprenda todo el tipo de diagramas que pueda.
Use el diagrama más apropiado para ilustrar el aspecto en el que desea enfocarse.
Proporcione una forma de relacionar diferentes diagramas (en mi experiencia este es el aspecto más descuidado y termina con un montón de modelos extremadamente detallados que no encajan entre sí !!!).
Revise constantemente los modelos para reflejar la nueva comprensión que obtiene durante el proceso de diseño.

Mi proceso "paso a paso" sería este:

Crea un prototipo No tiene que hacer mucho, en muchos casos, arrastrar algunos controles sobre el diseñador de formularios hará. Luego revise el prototipo con el cliente / usuario final. (Esta es la parte importante: si solo creas el prototipo y lo tiras al otro lado de la pared, no serviría de nada.) Explica cómo crees que funcionaría el software cuando muestres el prototipo y escuches lo que dice el cliente . De nuevo, escuchar es más importante que explicar. Después de eso, debe tener una comprensión sólida de lo que el cliente necesita.
Ahora normalmente saco papel y lápiz y comienzo a dibujar la estructura del módulo de alto nivel. Tal vez también las clases importantes, pero no todos los detalles de implementación. Después de este paso, sé qué módulos necesito, cuál es la responsabilidad de cada módulo, cómo puedo probar cada módulo.
La implementación se realiza de la manera que usted la conoce (al menos, lo hago más o menos de la manera en que lo describió). Pero solo implementa la funcionalidad básica básica al principio. De lo contrario, seguramente perderá funcionalidad crítica porque está demasiado ocupado agregando campanas y silbatos.
Enjuague y repita: Ahora tiene un programa con funcionalidad limitada, regrese a su cliente, muéstrelo, déjelo jugar con él. Mira cómo intentan usarlo: ¿dónde fallan? ¿Qué están buscando y no pueden encontrar?

Consejo de libro: Libéralo

Probablemente debería tomar una conferencia sobre Ingeniería de Software si está interesado en el proceso de diseño y desarrollo del software.

Las otras respuestas ya dieron algunas pistas con ese respeto; sin embargo, un aspecto importante que no debe descuidarse es que antes de comenzar su diseño, debe escribir lo que se supone que su software hace en forma de una especificación de requisitos de software :

Una especificación de requisitos de software es una descripción completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que los usuarios tendrán con el software. Los casos de uso también se conocen como requisitos funcionales. Además de los casos de uso, el SRS también contiene requisitos no funcionales (o suplementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación (como los requisitos de ingeniería de rendimiento, estándares de calidad o restricciones de diseño).

Tal documento lo ayuda a mantenerse enfocado, aclarar los casos de uso reales, encontrar fallas potenciales, definir ciertos objetivos (por ejemplo, con respecto al rendimiento). La especificación también será la base para verificar su implementación final (¿Su software hace lo que se supone que debe hacer?) Y lo ayudará a crear escenarios de prueba.