¿Mejores prácticas en la administración de componentes de complejidad/visualización en su software?

Question

Estamos creando herramientas para extraer información de la web. Tenemos varias piezas, como

• datos de rastreo de la web
información
• Extracto basa en plantillas & reglas de negocio
• Analizar los resultados en la base de datos de
• Aplicar la normalización & reglas de filtrado
• etc, etc

El problema es solucionar problemas & teniendo una buena "imagen de alto nivel" de lo que sucede en cada etapa.

¿Qué técnicas te han ayudado a comprender y gestionar procesos complejos?

• Utilizar las herramientas de flujo de trabajo como Windows Workflow Foundation
• encapsular funciones separadas en herramientas de línea de comandos & herramientas utilizar secuencias de comandos para vincularlos
• escribir en un idioma Específico de dominio (DSL) para especificar cosas qué orden debería suceder en un nivel superior.

Es curioso cómo se maneja un sistema con muchos componentes interactuantes. Nos gustaría documentar/comprender cómo funciona el sistema a un nivel más alto que el rastreo a través del código fuente.

Answer 1

El código dice lo que sucede en cada etapa. Usar una DSL sería una bendición, pero posiblemente no, si se produce a costa de escribir su propio lenguaje de scripting y/o compilador.

La documentación de nivel superior no debe incluir detalles de lo que ocurre en cada paso; debe proporcionar una visión general de los pasos y cómo se relacionan juntos.

buenos consejos:

• visualizar sus relaciones de esquema de base de datos.
• Use visio u otras herramientas (como la que ha mencionado, no la ha usado) para obtener descripciones generales del proceso (en caso de que pertenezca a la especificación de su proyecto).
• Asegúrese de que su código esté estructurado/compartimentado/etc.
• Asegúrese de tener algún tipo de especificación de proyecto (u otra documentación "general" que explique qué hace el sistema en un nivel abstracto).

No recomendaría la construcción de herramientas de línea de comandos a menos que realmente tenga un uso para ellas. No es necesario mantener herramientas que no usa. (Eso no es lo mismo que decir que no puede ser útil, pero la mayoría de lo que haces suena más como si perteneciera a una biblioteca en lugar de ejecutar procesos externos).

Answer 2

Yo uso AT & T famoso Graphviz, es simple y hace el trabajo muy bien. Es la misma biblioteca que usa Doxygen también.

Además, si hace un poco de esfuerzo puede obtener gráficos muy bonitos.

Olvidé mencionar, la forma en que la uso es la siguiente (porque Graphviz analiza scripts de Graphviz), utilizo un sistema alternativo para registrar eventos en formato Graphviz, entonces simplemente analizo el archivo Logs y obtengo un buen gráfico.

Answer 3

Mi empresa escribe functional specifications para cada componente principal. Cada especificación sigue un formato común, y utiliza varios diagramas e imágenes según corresponda. Nuestras especificaciones tienen una parte funcional y una parte técnica. La parte funcional describe lo que hace el componente en un nivel alto (por qué, qué objetivos soluciona, qué no hace, con qué interactúa, documentos externos que están relacionados, etc.). La parte técnica describe las clases más importantes en componentes y patrones de diseño de alto nivel.

Preferimos el texto porque es el más versátil y fácil de actualizar. Esto es un gran problema, no todos son expertos (ni siquiera decentes) en Visio o Dia, y eso puede ser un obstáculo para mantener los documentos actualizados. Escribimos las especificaciones en una wiki para que podamos vincular fácilmente cada especificación (así como los cambios de seguimiento) y permite un recorrido no lineal a través del sistema.

Para un argumento de autoridad, Joel recomienda las especificaciones funcionales here y here.

Answer 4

Encontré un dependency structure matrix una manera útil de analizar la estructura de una aplicación. Una herramienta como lattix podría ayudar.

Dependiendo de su plataforma y cadena de herramientas, existen muchos paquetes de análisis estáticos realmente útiles que podrían ayudarle a documentar las relaciones entre subsistemas o componentes de su aplicación. Para la plataforma .NET, NDepend es un buen ejemplo. Sin embargo, hay muchas otras para otras plataformas.

Tener un buen diseño o modelo antes de construir el sistema es la mejor manera de entender cómo se debe estructurar la aplicación, pero herramientas como las que mencioné pueden ayudar a aplicar las reglas arquitectónicas y, a menudo, el diseño que solo rastrea a través del código no puede.

Answer 5

El diseño de arriba hacia abajo ayuda mucho. Un error que veo es hacer que el diseño de arriba sea sagrado. Su diseño de nivel superior debe revisarse y actualizarse como cualquier otra sección de código.

Answer 6

No utilizaría ninguna de las herramientas que mencionó.

Debe dibujar un diagrama de alto nivel (me gusta el lápiz y el papel).

Diseñar un sistema que tiene diferentes módulos haciendo cosas diferentes, valdría la pena diseñar esto para que pueda tener muchas instancias de cada módulo que se ejecuta en paralelo.

Me gustaría pensar acerca del uso de múltiples colas para

• URL que se rastrearán
• páginas rastreadas desde la web
• Información extraída en base a plantillas & reglas de negocio
resultados
• Analizada
• normalizationed & resultados filtrados

Tendría programas simples (probablemente de línea de comandos sin UI) que leerían datos de las colas e insertarían datos en una o más colas (el rastreador alimentaría a las "URL para rastrear" y "Rastreado páginas de la web"), que puede usar:

• Un rastreador web extractora
• Un dato
• Un analizador
• un normalizador y Filterer

Éstos encajarían entre las colas, y podría ejecutar muchas copias de estos en equipos separados, lo que permite escalar.

La última cola se podría alimentar a otro programa que realmente publique todo en una base de datos para su uso real.

Answer 7

Es importante dividir estos componentes a lo largo de su ciclo de vida de desarrollo de software: tiempo de diseño, tiempo de desarrollo, prueba, lanzamiento y tiempo de ejecución. Solo dibujar un diagrama no es suficiente.

Descubrí que la adopción de una arquitectura de microkernel puede realmente ayudar a "dividir y conquistar" esta complejidad. La esencia de la arquitectura microkernel es:

• Procesos (cada uno ejecuta el componente en un espacio de memoria aislado)
• Hilos (cada componente se ejecuta en un hilo separado)
• Comunicación (componentes se comunican a través de una única, simple mensaje de canal que pasa)

I han escrito una bastante complejos sistemas de procesamiento por lotes que suenan similar a su sistema usando:

Eac componente de mapas h a .NET ejecutable vidas ejecutables se gestionan a través de Autosys (todo en la misma máquina) La comunicación se realiza a través de TIBCO Rendezvous

Si puede utilizar un conjunto de herramientas que proporciona un poco de introspección tiempo de ejecución, aún mejor. Por ejemplo, Autosys me permite ver qué procesos se están ejecutando, qué errores han ocurrido mientras TIBCO me permite inspeccionar las colas de mensajes en tiempo de ejecución.

Answer 8

Me gusta usar NDepender para utilizar la base de código .NET de ingeniería inversa.La herramienta viene con varias características de visualización grandes como:

gráfico de dependencias:

Dependencia Matrix:

Código visualización métrica a través treemaping: