文章来源：百度空间
什么是系统分析？
   在软件行业中，大家都认为系统分析员应该是个非常高深的角色，甚至很多系统分析员在一些大公司里面的待遇要比部门经理还要高。所以，也成为很多程序员人生中的一个目标。
    定义
   系统分析的工作，在最初的定义中，系统分析员是将用户的原始需求转换成程序员可以理解的形式，由程序员来进行原始编码实现。
   系统分析员一般要完成三个任务。
1）需求调研：带领需求调研人员与用户接触交流获取完整的用户需求。
2）需求分析：分析用户的需求，同时不断与用户进行交流，形成需求的稳定版本---在这里也就是通过对需求的分析获得系统整体架构，然后指导分析人员构建完成分析模型，当然这也是需求管理重要的一步。
3）设计：指导设计人员熟悉分析模型，并据此完成设计模型的开发工作，然后交给程序员进行编码实现。

现实状况
在国内的实际工作中，开发人员目前往往是一人多职，每一个人几乎是从需求调研开始一直做到编码结束的。而国内的项目经理则更要求是多面手，从项目管理到需求，分析，设计，编码，几乎要求无所不会，无所不能才可以。
因此往往造成工作失去计划，因为项目经理太忙没有时间制定计划，或者是制定了一个形式上的计划，以至于项目计划本身的可操作性就非常差。
   随后，因为项目经理本身还要参与开发，使得他没有精力来进行项目过程的监控管理，没有时间跟踪其它开发人员的开发进度，检查其它开发人员的开发结果的有效性，最终导致整个项目的完全失控，或者远超时限的延期。

一些建议
对于一些比较大的工程项目，或者一些可以进行比较规范的管理的软件公司，本书有如下建议。
   如果要进行真正的工程化开发，在软件成为一个产业的时候，原始方式就已经不可用了。因为它使得很多高素质的人员不得不从事一些比较机械化的工作，无法更好地发挥一个高层次人才的作用，造成很大的资源浪费。
   比如说：对于一个简单的递归调用，完成一个基本数组的增加等这样的一些任务，每一个现在的开发人员都可以轻而易举地做到，但是这样的事情让开发人员来做，往往是大材小用。因为系统分析员也不得不从事普通的编码工作，来撰写这样的简单过程，项目组应该让他们把自己的精力集中在一些难点，以及一般的开发人员无法解决的问题上。
   现在，开发人员既要了解业务，又要熟悉开发，这要求的确是很高的。如果项目组进行了人员的职能划分，这样就可以大量减少开发人员对业务的了解，而提高开发效率，另外一部份人（下面是需求人员）专门从事需求工作来对客户的业务进行了解。
   在进行分析模型开发工作时，建议由系统分析员带领需求人员进行绘制，设计人员参与讨论------主要是为了让设计人员明白需求中一些需要特别注意的问题，了解需求中与自己相关业务的基本过程。

   如果一个公司职能划分足够明确清晰，并且开发人员素质达到了一定的层次，分析模型就只需由需求人员来给制，设计人员只需要负责开发设计模型就可以了。

Layers架构模式

　　在收集到用户对软件的要求之后，架构设计就开始了。架构设计一个主要的目的，就是把系统划分成为很多"板块"。划分的方式通常有两种，一种是横向的划分，一种是纵向划分。

　　横向划分将系统按照商业目的划分。比如一个书店的管理系统可以划分成为进货、销售、库存管理、员工管理等等。

　　纵向划分则不同，它按照抽象层次的高低，将系统划分成"层"，或叫Layer。比如一个公司的内网管理系统通常可以划分成为下面的几个Layer:

　　一、网页，也就是用户界面，负责显示数据、接受用户输入；

　　二、领域层，包括JavaBean或者COM对象、B2B服务等，封装了必要的商业逻辑，负责根据商业逻辑决定显示什么数据、以及如何根据用户输入的数据进行计算；

　　三、数据库，负责存储数据，按照查询要求提供所存储的数据。

　　四、操作系统层，比如Windows NT或者Solaris等

　　五、硬件层，比如SUN E450服务器等

　　有人把这种Layer叫做Tier，但是Tier多带有物理含义，不同的Tier往往位于不同的计算机上，由网络连接起来，而Layer是纯粹逻辑的概念，与物理划分无关。

Layers架构模式的好处是：

　　第一、任何一层的变化都可以很好地局限于这一层，而不会影响到其他各层。

　　第二、更容易容纳新的技术和变化。Layers架构模式容许任何一层变更所使用的技术

Facade架构模式

　　外部与一个子系统的通讯必须通过一个统一的门面（Facade）对象进行，这就是Facade模式。

　　现代的软件系统都是比较复杂的，设计模式的任务就是协助设计师处理复杂系统的设计。

　　设计师处理复杂系统的一个常见方法便是将其"分而治之"，把一个系统划分为几个较小的子系统。但是这样做了以后，设计师往往仍然会发现一个子系统内仍然有太多的类型要处理。而使用一个子系统的使用端往往只关注一些特定的功能，却要同时与子系统内部的许多对象打交道后才能达到目的，请见下面的对象图。

　　这就是一种不便，它使得系统的逻辑变得不必要的复杂，维护成本提高，复用率降低。

　　用一个范例说明，中国大陆的医院便是一个子系统，按照部门职能，这个系统可以划分为挂号、门诊、划价、化验、收银、取药等。看病的病人要与这些部门打交道，就如同一个子系统的使用端与一个子系统的各个类型打交道一样，不是一件容易的事情。

　　首先病人必须先挂号，然后门诊。如果医生要求化验，病人必须首先划价，然后缴款，才能到化验部门做化验。化验后，再回到门诊室，请见下面的对象图。

图5、描述病人在医院里的体验。图中的方框代表医院。

　　解决这种不便的方法便是引进Facade模式。仍然通过医院的范例说明，可以设置一个接待员的位置，由接待员负责代为挂号、划价、缴费、取药等。这个接待员就是Facade模式的体现，病人只接触接待员，由接待员负责与医院的各个部门打交道，请见下面的对象图。

图6、描述经过Facade模式的改装后，病人在医院里的体验。图中的方框代表医院。

Facade模式要求一个子系统的外部与其内部的通讯必须通过一个统一的门面（Facade）对象进行。Facade模式提供一个高等级的接口，使得子系统更易于使用。

　　使用了Facade模式之后，本章的第一个图中所描述的一个子系统的使用端对象所面对的复杂关系就可以简化为下面这个样子。

图7、Facade架构模式的结构图

　　描述经过Facade模式的改装后，一个子系统的使用端与子系统的关系。图中的大方框代表一个子系统。

　　就如同医院的接待员一样，Facade模式的门面类型将使用端与子系统的内部复杂性分隔开，使得使用端只需要与门面对象打交道，而不需要与子系统内部的很多对象打交道。

Mediator架构模式

Mediator模式包装了一系列对象相互作用的方式，使得这些对象不必互相明显参照；从而使它们可以较松散地耦合。当这些对象中的某些对象之间的相互作用发生改变时，不会立即影响到其它的一些对象之间的相互作用；从而可以保证这些相互作用可以彼此独立地变化。

　　在下面的示意图中有大量的对象，这些对象既会影响别的对象，又会被别的对象所影响，因此常常叫做同事（Colleague）对象。这些同事对象通过彼此的相互作用形成系统的行为。从图中可以看出，几乎每一个对象都需要与其它的对象发生相互作用，而这种相互作用表现为一个对象与另一个对象的直接耦合。

图8、这是一个过度耦合的系统

　　通过引入调停者对象（Mediator），可以将系统的网状结构变成以中介者为中心的星形结构，如下图所示。在这个星形结构中，同事对象不再通过直接的联系与另一个对象发生相互作用；相反地，它通过调停者对象与另一个对象发生相互作用。调停者对象的存在保证了对象结构上的稳定，也就是说，系统的结构不会因为新对象的引入造成大量的修改工作。

图9、这是一个使用了Mediator架构模式之后的结构图

　　比较传统的设计方法，面向对象的技术可以更好地协助设计师管理更为复杂的系统。一个好的面向对象的设计可以使对象之间增加协作性（Collaboration），减少耦合度（Coupling）。一个深思熟虑的设计会把一个系统分解为一群相互协作的同事对象，然后给每一个同事对象以独特的责任，恰当的配置它们之间的协作关系，使它们可以在一起工作。

　　在Mediator模式中，所有的成员对象都可以协调工作，但是又不直接相互管理。这些对象都与一个处于中心地位的调停者对象发生紧密的关系，由这个调停者对象进行协调工作。这个协调者对象叫做调停者（Mediator），而调停者所协调的成员对象称做同事（Colleague）对象。

　　在Colleague对象内部发生的事件会影响到所有的同事，但是这种影响不是以直接管理的方式直接传到其它的对象上的。记住在小组的成员增加时，这样的相互作用关系是以比指数更快的方式增加的。相反，这种影响仅仅直接影响到调停者对象，而调停者对象反过来会协调其它的同事，形成整个系统的行为。

　　如果小组的成员增加时，调停者对象可能会面临修改，而其它的同事则可以装做不知道这个新的成员一样，不必修改。反过来，如果小组的成员之一被从系统中删除的话，调停者对象需要对此做出修改，而小组中其它的同事则不必改动。

Interpreter架构模式

　　给定一个语言之后，Interpreter模式可以定义出其文法的一种表示，并同时提供一个直译器；使用端可以使用这个直译器来解释这个语言中的句子。

　　如果某一类型问题一再地发生的话，那么一个有意义的做法就是将此类型问题的各个实例表达为一个简单语言中的语句。这样就可以建造一个直译器，通过解释这些语句达到解决问题的目的。

　　例如，依照一个匹配模式搜寻字符串便是一个常见的问题。与其为每一个匹配模式建造一个特定的算法，不如建造一个一般性的算法处理各种常规表达式。当接到一个指定的常规表达式时，系统使用一个直译器解释这个常规表达式，从而对字符串进行匹配。

　　再比如VBA（Visual Basic for Applications）就不仅仅出现在微软的Office系列软件中，并且可以供第三厂家出产的软件嵌入使用；Crystal Reports报表生成软件也包括了一个便于使用的宏语言，使用户可以执行较为复杂的命令操作。一般而言，将VBA或者其它的语言软件嵌入到自己的软件产品中，可以使产品定制化（Customization）能力大大增强，但是这些宏语言引擎往往都很昂贵。

　　现在要介绍的Interpreter模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。熟悉了这个模式以后，一个没有接收过形式语言和编译器的正规训练的设计师也可以自行设计一个简单的直译器，以便为使用端提供一个简单语言，或者在系统内部使用一个简单语言描述一个合适的问题。

　　语言、直译器和剖析器

Interpreter模式只描述直译器是怎样工作的，并不指明怎样在执行时创建新的直译器。虽然广义地讲直译器不一定要有一个剖析器（Parser），但是使用剖析器仍然是最常见的建立直译器的办法。一个剖析器可以从一个档或命令行读入文字性命令，并创建直译器。

剖析器是一种能够识别文字并将文字按照一定规则进行分解以便进一步处理的对象。剖析器能够识别的字符串叫做语言。通常建立的小型计算机语言是与环境无关的语言，也就是遵循一定的文法的文字模式，所谓文法，便是决定怎样将语言的元素组合起来的规则的集合。剖析器便是根据组合规则将字符串分解的。

　　抽象地讲，语言并不一定是以字符串的形式表达的。在Interpreter模式里面所提到的语言是指任何直译器对象能够解释的任何组合。在Interpreter模式中，需要定义一个代表文法的命令类型的等级结构，也就是一系列的组合规则；每一个命令对象都有一个解释方法，代表对命令对象的解释。

　　命令对象的等级结构中的对象的任何排列组合都是一个语言，而剖析器的工作便是将一个文字性语言翻译成为等效的直译器语言。因此，直译器往往需要剖析器。

　　认识Jack吗？

　　剖析器生成器（Parser Generator），常常称为编译器的编译器（Compiler Complier）。Sun Microsystem提供一个专为Java程序员发明的强大的剖析器生成器，最初叫做Jack，后来改名为JavaCC。

　　要使用JavaCC，必须使用它提供的脚本语言编写一个脚本，然后执行JavaCC生成Java源代码。这生成的源代码就是所需的剖析器。现在Sun已经不再负责JavaCC的研发，对JavaCC感兴趣的读者可以从http://www.experimentalstuff.com/Technologies/JavaCC得到免费的JavaCC和相关数据。

JavaCC最早命名为Jack是为了与一个早就广泛使用的剖析器生成器YACC谐音。如果读者已经熟悉了YACC，可以使用YACC达到同样的目的；只是相比之下JavaCC更容易得到Java程序员的喜爱。