多进程程序设计的方法思考及相关工具

多进程程序设计是分而治之策略的实现手段，目前具体的方法我还在学习阶段，以下仅仅是我的初步思考。

面对一个问题时，可以自上而下地分析系统内需要处理哪些事情，在得到初步结论后，可以自下而上的构建（实现）。自上而下的分析并不是为了在一开始找出所有需要做的事情，并分析清楚它们之间的关系——那是瀑布模型的做法，这里的自上而下只是先给问题做个全局的鸟瞰，为自下而上的构建提供大方向以及一个基本靠谱的起点（即初步地分析至少要做哪些事情）。而自下而上的构建也不是为了直接以此得到一个完整的系统，而只是先打好基础：对于那些必须要做的事情，先一件一件地做好，在这个过程中，会引出这些事情的依赖项：必须做的事情的依赖项也是必须做的事情，这样的过程可以逐渐地使我们把所有必须做的事情找出来，而这个过程不真正去对必须做的事情做编码、调试和测试是无法凭空想和猜测来完成的。当自下而上地把所有能找到的必须做的事情都做完，然后再至上而下地分析，这时会比第一次自上而下时更能理解整个系统和要解决的问题，这时能够更容易地知道整个系统应该怎样的——比第一次自上而下时更容易。

自上而下的分析已经是多进程程序设计以外的另一个问题了，这里说说自下而上的构建过程需要些什么样的条件保障。

1. 由于自下而上的构建过程中，一个小问题的解决形式就是一个小的独立的程序，所以以后必须有办法能够把这些小程序整合为一个系统。
2. 由于一开始写这些小程序时，考虑的仅仅是它要解决的那一个问题，并且其使用环境（即最终的整个系统）还不明朗，所以这时的接口协议只能根据要解决的问题本身来设计，而无法顾及到今后使用它的程序。这就意味着，当以后发生协议兼容问题时，需要有办法对进程间的通信数据进行转换，以适配不同的协议，而且这个适配对于已有的所有程序必须是透明的——也就是说不需要修改已有的任何程序。
3. 由于编写一个小程序时，无法得知今后的运行环境，所以当它向外界环境索取数据或服务时，它只知道自己需要什么，但却不知道该向谁去要，那么今后整合时必须有办法把服务或数据的请求交给适当的程序，然后把结果再交给适当的程序（不一定是发出请求的程序），这个过程对已有程序也必须是透明的。

就多个小程序的整合来说，最典型的做法就是编写一些shell脚本，所以我思考的方向重点放在如何在shell编程中提供这些保障，而且必须足够简单，因为我在shell编程方面也是新手。而这些保障，很可能需要编写一些小工具来提供。就目前shell里简单易用的整合手段来说，主要就是匿名管道（使用符号“|”）。然而由于多个进程所组成的结构往往是带环或树的结构，并不一定是线性的，所以匿名管道只是基础的工具之一，仅仅靠它无法完全解决问题。