我们正在构建用于从网上挖掘信息的工具。我们有几件，从网络如在软件中管理复杂性/可视化组件的最佳实践？
问题是排除故障问题&对每个阶段发生的事情都有很好的“高层次图片”。
什么技术帮助您理解和管理复杂的过程？
只是好奇你如何得到一个系统与许多交互组件的句柄。我们希望文档/了解系统如何在比追溯源代码更高的层次上工作。
该代码说明了每个阶段会发生什么。使用DSL将是一件好事，但如果它是以编写自己的脚本语言和/或编译器为代价的，则可能不会。
更高级别的文档不应包括每一步发生的细节;它应该提供步骤的概述以及它们如何相互关联。
很好的提示：
我不会推荐构建命令行工具，除非您实际上已经使用它们。无需维护您不使用的工具。 （这不同于说它不可用;但是你所做的大部分听起来更像是属于图书馆，而不是执行外部过程）。
感谢您的提示 - 我喜欢visio/specs，但不可避免地他们似乎过时了。理想情况下，可视化可能来自代码本身（如db模式关系）。 同意 - 命令行工具本身没用，但有时脚本比代码更容易扫描。 – Kalid 2008-11-20 01:57:17
我公司为每个主要组件编写functional specifications。每个规范都遵循一个通用格式，并根据需要使用各种图表和图片。我们的规格有一个功能部分和一个技术部分。功能部分描述了组件在高级别（为什么，它解决了什么目标，什么它没有做，它与什么交互，与相关的外部文档等）做了什么。技术部分描述组件和任何高级设计模式中最重要的类。
我们更喜欢文字，因为它是最通用和最容易更新的。这是一件大事 - 并不是每个人都是Visio或Dia的专家（或者甚至是像样的），这可能会阻碍文档的更新。我们在维基上编写规范，以便我们可以轻松地链接每个规范（以及跟踪更改），并允许通过系统进行非线性漫游。
我发现一个dependency structure matrix一个有用的方式来分析应用程序的结构。像lattix这样的工具可以提供帮助。
根据您的平台和工具链，有很多真正有用的静态分析包可以帮助您记录子系统或应用程序组件之间的关系。对于.NET平台，NDepend就是一个很好的例子。不过其他平台还有很多。
构建系统之前有一个好的设计或模型是理解团队应该如何构建应用程序的最佳方式，但像我提到的那些工具可以帮助实施架构规则，并且通常会让您深入了解只是通过代码拖网的设计不能。
自上而下的设计帮助了很多。我看到的一个错误是使顶级设计成为神圣的。您的顶级设计需要像任何其他代码部分一样进行审查和更新。
我不会使用你提到的任何工具。
你需要绘制一个高级图（我喜欢铅笔和纸）。
我会设计一个系统，使不同的模块做不同的事情，这是值得的设计这个，这样你可以有许多并行运行的每个模块的实例。
我会考虑使用多个队列
你必须简单，将来自队列中读取数据以及将数据插入一个或多个队列（爬网将同时并行“要抓取的网址”和“爬程序（可能是没有用户界面的命令行）从网上”）页面，您可以使用：
这些将适合队列之间，你可以在单独的PC上运行这些的许多副本，这可以扩展。
最后一个队列可以被传送到另一个程序，该程序实际将所有内容都发布到数据库中供实际使用。
在整个软件开发生命周期中划分这些组件非常重要 - 设计时间，开发时间，测试，发布和运行时间。仅画一张图是不够的。
我发现采用微内核体系结构真的可以帮助“分而治之”这种复杂性。微内核结构的实质是：
我写使用哪个音质类似于系统相当复杂的批处理系统：
EAC H分量映射到.NET可执行 可执行寿命是通过Autosys（全部在同一台机器上）管理 通信是通过TIBCO交会
如果你可以使用一个工具包，提供一些运行时的自省，甚至更好。例如，Autosys让我看到正在运行的进程，在TIBCO允许我在运行时检查消息队列时发生了什么错误。
我喜欢使用NDepend来逆向设计复杂的.NET代码库。该工具提供了几个巨大的可视化功能，如：
依赖图： 
相关性矩阵：通过treemaping 
代码度量可视化： 
如果你想给的答案你，如果你投他们的话就不会受伤。 ;） – Till 2008-11-23 17:58:58
完成并完成:) – Kalid 2008-11-24 22:16:54