2.1 分析面临的主要问题

自从软件工程学问世以来，先后出现过多种分析方法。各种分析方法从不同的观点提出了认识问题域并建立系统模型的理论与技术，使软件开发走上了工程化和规范化的轨道。然而，分析工作仍然面临着许多难题。随着时代的发展和科技的进步，人们对软件的要求越来越高，分析所面临的问题也越来越突出。主要的问题包括：对问题域和系统责任的正确理解、人与人之间的正确交流、如何应对需求的不断变化以及软件复用对分析的要求。
1问题域和系统责任
在过去的几十年中，人们都认为大规模的软件开发是一项冒险的活动。人们之所以这么认为，其根本原因在于软件的复杂性，而且这种复杂性还在不断地增长。
软件的复杂性首先源于问题域（problem domain）和系统责任（system responsibility）的复杂性。
问题域：被开发系统的应用领域，即在现实世界中这个系统所涉及的业务范围。
系统责任：被开发系统应该具备的职能。
这两个术语的含义在很大部分上是重合的，但不一定完全相同。例如，要为银行开发一个金融业务处理系统，银行就是这个系统的问题域。银行的日常业务（如金融业务、个人储蓄、国债发行和投资管理等）、内部管理及与此有关的人和物都属于问题域。尽管银行内部的人事管理属于问题域，但是在当前的这个系统中它并不属于系统责任。

像对计算机信息的定期备份这样的功能属于系统责任，但不属于问题域。图21是对本例的一个图示。

图21中，左边的椭圆所示的范围为问题域部分，右边的椭圆所示的范围为系统责任部分，二者之间有很大的交集。
对问题域和系统责任进行深入的调查研究，产生准确透彻的理解是成功地开发一个系统的首要前提，也是开发工作中的第一个难点。这项工作之所以困难是由于以下原因：
 软件开发人员要迅速、准确、深入地掌握领域知识。
俗话讲，隔行如隔山。要开发出正确而完整的系统，就要求软件开发人员必须迅速地了解领域知识，而不能要求领域专家懂得全部的软件开发知识。这对软件开发人员来说是一个挑战。不但如此，分析员对问题域的理解往往需要比这个领域的工作人员更加深入和准确。许多领域的工作人员长期从事某一领域的业务，却很少考虑他们司空见惯的事物所包含的信息和行为，以及它们如何构成一个有机的系统。系统分析员则必须透彻地了解这些。此外，软件开发人员还要考虑如何充分发挥计算机处理的优势，对现实业务系统的运作方式进行改造，这需要系统分析员具有比领域专家更高明的见解。这是因为许多系统的开发并不局限于简单地模拟问题域中的业务处理并用计算机代替人工操作，还要在计算机的支持下，对现行系统的业务处理方式做必要的改进。
 现今的系统所面临的问题域比以往更为广阔和复杂，系统比以往更为庞大。
随着计算机硬件性能的提高和价格的下降，以及软件技术的发展使得开发效率的不断提高，人们把越来越多、越来越复杂的问题交给计算机解决。相对而言，问题域和系统责任的复杂化对需求分析的压力比其他开发阶段更为巨大。
OOA强调从问题域中的实际事物以及与系统责任有关的概念出发来构造系统模型。这使得系统中的对象、对象的分类、对象的内部结构以及对象之间的关系能良好地与问题域中的事物相对应。因此，OOA非常有利于对问题域和系统责任的正确理解。
2交流问题
如果分析阶段所产生的文档使得分析员以外的其他人员都难以读懂，那就不利于交流，随之而来的是各方对问题的理解会产生歧义。这会使彼此的思想不易沟通，并容易隐藏许多错误。对软件系统建模涉及如下人员之间的交流：
 开发人员与用户及领域专家间的交流。为了准确地掌握系统需求，双方需要采用共同的语言来理解和描述问题域。以往多采用自然语言描述需求，效果并不理想。
 开发人员之间的交流。分析人员在系统建模时经常需要分工协作，对问题要进行磋商，并要考虑系统内各部分的衔接问题。分析人员与设计人员之间也存在着工作交接问题，这种交接主要通过分析文档来表达，也不排除口头的说明和相互讨论。这些要求所采用的建模语言和开发方法应该一致，且不要过于复杂。
 开发人员与管理人员之间的交流。管理人员要对开发人员的工作进行审核、确认、进度检查和计划调整等。这就需要有一套便于交流的共同语言。这里“语言”是广义的，它包括术语、表示符号、系统模型和文档书写格式等。
OOA充分运用人类日常活动中采用的思维方法和构造策略来认识和描述问题域，构造系统模型，并且在模型中采用了直接来自问题域的概念。因此，OOA为改进各类人员之间的交流提供了最基本的条件——共同的思维方式和共同的概念。
3需求的不断变化
社会的发展是迅速的，这就要求软件系统也要不断地随之变化。此外，客户的主客观因素、市场竞争因素、经费与技术因素，都会影响需求的变化。显然，软件开发者必须以合作的态度满足用户需求。于是系统的应变能力的强弱，便是衡量一种分析方法优劣的重要标准。那么，系统中哪些因素是容易变化的？哪些因素是比较稳定的？人们在实践中发现：当需求发生变化时，系统中最容易变化的部分是功能部分（对OO方法而言则是对象的操作或操作的协作部分）；其次是对外的接口部分；第三是描述问题域事物的数据（对OO方法而言即对象的属性）；相对稳定的部分是对象。
OOA之所以对变化比较有弹性，主要是获益于封装和信息隐蔽原则。它以相对稳定的成分（对象）作为构成系统的基本单位，而把容易变化的成分(属性及部分操作)封装并隐藏在对象之中，它们的变化主要影响到对象内部。对象只通过接口对外部产生有限的影响。这样就有效地限制了一处修改处处受牵连的“波动效应”。从整体范围看，OOA以对象作为系统的基本构成单位，对象的稳定性和相对独立性使系统具有一种宏观的稳定效果。即使需要增加或减少某些对象，其余的对象仍能保持相对稳定。
4软件复用的要求
软件复用是提高软件开发效率、改善软件质量的重要途径。20世纪80年代中期以前的软件复用，主要着眼于程序（包括源程序和可执行程序）的复用。到20世纪80年代末期，人们已开始提出对软件复用的广义理解，注意到分析结果和设计结果的复用将产生更显著的效果。分析结果的复用是指把分析模型中的可复用部分用于多个系统的开发，并要求一个分析模型可在多组条件下予以设计与实现。此外，还可以在把一个老系统改造为基于新的软硬件支持的新系统时，尽量地复用旧的分析结果。
OO方法的继承本身就是一种支持复用的机制，它使特殊类中不必重复定义一般类中已经定义的属性与操作。无论是在分析、设计，还是编程阶段，继承对复用带来的贡献都是显而易见的。
由于OOA模型中的一个类完整地描述了问题域中的一类客观事物，并且它是独立的封装实体，它很适合作为一个可复用成分。由一组关系密切的类（如具有一般—特殊结构、整体—部分结构或一组相互关联的类）可以构成一个粒度更大的可复用成分。在OO开发中，先在OOA阶段建立的是一个符合问题域、满足用户需求的OOA模型，然后再根据具体实现条件进行系统设计，这样针对一个分析模型可有多个实现，使得OOA结果能够通过复用而扩展为一个系统族。