因为系统分析需要对根据系统的需求，综合公司的各个方面的能力来进行评估，考虑系统实施的各种风险因素，并需要为系统架构提供建设性的意见和方案，关系项目的成败。

如何理解面向对象的系统分析方法

使用MVC进行项目开发已经有一段时间了，在这段时间里感触最深的就是自己对宏观性面向对象分析方法的缺乏。面向对象分析是当今流行的系统分析方法之一，下面就谈谈在做项目的过程中我的一些小经验。

在面对简单系统时程序员可以很顺利的提出问题的解决方案，并且一般情况下都是可行的。这是由于问题域关系简单，所涉及到的内部构造、联系比较容易解释。而对于当前越来越复杂的系统，其问题域也就显示的越来越复杂，而且内部的关系也不是很容易解释，有些大的系统常常超出了人的解决问题的能力。在这种情况下，以往的面对过程的解决方法已经不能满足日益增长的复杂系统分析的需要，在这种情况下，面向对象的分析方法就显得尤为总要了。

在面向对象设计领域中，在横向上把问题域分为数个不同的、低耦合、高内聚的问题域，而在纵向上又继续分解各个不同的小的问题域，最后分解为叶节点问题域，从而解决问题。在面对对象分析方法中，用数个对象间的消息传递来完成整个问题。

下面看一看复杂系统的5个属性：

1． 杂性经常是以层次的形式表现出来，复杂系统是由相互关联的子系统组成，而这些子系统又是由他们各自的子系统构成，并由此类推到最底层的基本构件。

2． 对系统中最基本的构件的选择是任意的，而且在很大程度上取决于系统观察者的判断力。

3． 一般而言，各构件内的连接总是要强于构件间的连接。在从构件的低频动态中分离出高频动态时，这一属性是相当有用的。这是因为高频动态涉及到各部件的内部结构，而低频动态涉及到构件间的交互。

4． 层次系统通常都是由仅仅少数不同的子系统通过不同的排列组合方式组成。

5． 我们发现正运行的复杂系统总是由以前运行的简单系统演化而来……任何胡乱凑合设计出来的复杂系统都不可能正常运转，也不可能被修补好。我们必须由运行中的简单系统开始。

对于第一点，正像我上面所说的那样，系统是层次结构的。能够给一个复杂的系统进行正确的层次分析，才能够保证对系统的正确估计，包括可行性、可维护性、可扩展性……等等。而且对于日后对该系统进行维护(maintenance)、演化(evolution)、维持(preservation)都能够很好的支持。

对于其中的第二点，强调了观察者的判断力，其实我认为其中也包括观察者的身份角度。对于一个系统而言，观察者并不是只进行分析设计的工程师，编码阶段的程序员，还应该包括用户等所有这些同该系统有关的人员。作为不同的人员，对于系统就有不同的观察点、观察角度、身份等特殊因素。因此在不同身份的人（指参与者）甚至同一身份的人眼中说观察到的系统特性都是不尽相同的。在大学里大家都接触过透明性的概念，这就是不同观察者所观察角度不同的直观反应。对于用户来说，基本上底层的操作、算法、通讯对于他们来说都是透明的，他们根本不用理会（其实也不知道）内部用了什么。而对于一个负责某模块的程序员来说就不会考虑其他模块的实现，对于他们来说其他模块是透明的，他们只需要负责管理好提供的模块接口就OK了。

对于第三点，讲的就是面对对象分析设计的方向，在面对对象分析设计系统时，被分解的各个模块一定要做到高内聚、低耦合。有良好高内聚、低耦合系统常常会很容易维护，一个地方改动通常不需要牵扯到大的改动，维护行强。而且对于像VC程序这种更要求效率的程序来说，高内聚、低耦合也可以提高程序的运行期效率，应为对象内部的调用一般情况下会相比模块间的调用占用更少的执行时间，这样将高频动态封装在一个对象内部就会一定程度上提高程序运行期执行效率。

第四点则说明了面向对象程序设计对程序设计可复用性的优点。在这点中所“层次系统由仅仅少数不同的子系统构成”那么多数子系统在不同的复杂系统中都是能够重复使用的。比如说建筑一栋大厦和建筑桥梁，虽然两者都是复杂的系统，但是对于其结构中就会有很多相似甚至相同之处，没有必要建筑好大厦回头建筑桥梁的时候又要重新设计每一快砖瓦。

第五点提醒我们在系统设计时，尽量使用以往能够正常运行的子系统来重新构件新的系统。这一点不仅说明第四点中的复用性，而且也说明了一个我们常常要犯的错误。就是将并没有通过严格测试的子系统，匆忙的加入到大系统中，这样做不利于对系统的基层，常常引入了其他错误，使得系统频频崩溃，最严重会导致系统的重新分析。

这是我对面向对象的一点心得体会，虽然我们大家在平时工作中所面对的问题、问题域不同，使用的开发工具不同，但是面向对象是一种思维方式，有利于分析、解决问题的一种方法，并不和任何语言挂钩（当然语言对于面向对象特性的支持程度有所不同）。所以希望各位同事能够尽量使用科学的方法分析解决问题，形成一种设计模式，以供大家互相交流。

软件设计是一种艺术，也是一门工程学。