《大象：thinking in uml 》(第二版) 10章 需求分析

只供参考，喜欢请支持正版图书

10.1 关键概念分析

10.1.2 现在行动：建立概念模型

10.1.2.1 获取概念用例

10.1.2.2 分析概念用例

10.1.2.3 建立概念模型

在5.6.3分析模型的意义一节中作者介绍过，分析模型是采用MVC模式，将用例场景中描述的业务分解为边界（操作界面和展示界面）、控制（业务逻辑）和实体（业务数据），用这三个元素建立实现用例场景的对象模型。
这就引出了软件架构的问题。的确是这样，每一个小步都可以理解为系统中的一个功能单元，或者说最小的操作集。系统只有将所有的操作集有机地组合起来才能完成业务，才能称为一个系统。所以我们必须要考虑第一步如何到第二步的问题。这个问题显然是由软件架构来解决的，甚至最小最简单的系统都是如此。读者可能会感到迷惑，感觉不到软件架构在哪里。有读者或者在想，我们之前做过的项目根本就没考虑过软件架构，不也完成了吗？事实上软件架构一直都在，只不过被人们忽略了。

举例来说，最简单和最普遍的做法是采用数据库。第一步创建申请单完成后，申请单被保存到数据库中，第一步结束。第二步开始的时候，操作员要从数据库中将申请单读出来，并且填写自己的数据，再次存入数据库……如此这般直到整个业务完成。大部分项目就是这样做的吧？尽管你可能没去想，但这就是最简单的做法。即使简单如此，它也是由软件架构来支持的。什么架构呢？这就是我们非常熟悉的Client/Server架构。我们可以用图10.8来表示上述做法
例如，我们还可以采用工作流来做步骤衔接的工作。也就是说，我们在软件架构里选用了工作流。那么大致上，软件架构的示意可以用图10.9来表示
相应地，如果采用这个架构，如图10.7所示的实现过程就应该改成如图10.10所示的过程了。为了方便起见，作者将步骤一和步骤二绘制到同一张图里，请注意椭圆框内的消息，读者从中可以看出两个操作者之间是如何通过工作流引擎协作的

图10.10　加入了工作流的分析类场景示例——创建申请单

10.1.3 进一步讨论

10.1.3.1 第一个讨论：概念模型和领域模型

领域模型不一定针对业务，它针对的是问题。领域模型是针对用户档案结构这一问题来建立领域模型的。在现实的业务中并没有用户档案结构这样一项业务，客户也并不关心用户档案在计算机里是怎样一个结构。之所以要为
之建模，是因为在分析业务过程中我们认为由于业务都是围绕用户档案进行的，并且比较复杂，用户档案应当有一个好的结构以应对复杂的业务。所以值得提出这样一个问题，然后通过领域建模来寻求解决方案

10.1.3.2 第二个讨论：软件架构的引入

请读者回想你们曾经做过的项目，你们在选择软件架构时，是否考虑过与业务相结合？是从业务的角度来选择软件架构呢，还是从技术的角度来选择软件架构？在很多项目里，甚至在需求都还没有搞清楚前，就已经决定了我要用Struts+Hibernate；我要用J2EE+Websphere；我要用JSF+Spring+iBatis……

做出这样的决定是有些草率的，决定者仅仅是从纯技术的角度来考虑，最近流行什么架构啊，什么技术比较先进啊等等，这有些本末倒置了。软件架构或者技术框架是用来解决问题的。换句话说，架构和框架的意义在于它们是否能很好地解决业务问题，而不是技术如何先进

10.2 业务架构

相信很多人抱有这样的观点。但是，请看看近年来火得不得了的ERP软件如SAP、PeopleSoft等吧，SAP的同一个ERP产品，在许多行业都有成功实施的案例。不但是在同一行业不同企业，而且跨行业，从咨询业到制造业到商业，实施的都是那一套ERP产品。SAP的项目实施过程与我们平时做的项目截然不同，开发工作量非常小，绝大部分需求都是通过配置来完成的，几个人就可以实施上千万甚至上亿的项目。那么，你还认为行业软件不可能做到通用吗？

SAP为什么能做到，不是因为SAP采用了多么先进的技术架构（事实上SAP的技术架构在我们看来还相当古旧——十年前的C/S架构），而是因为SAP把业务做到了极致，它已经建立起了那些可以搭建业务平台的积木。再复杂和迥异的需求，都可以用这些积木搭建出来。

这些积木就是业务架构！

在项目开发过程中，当我们获得了一份需求时，如果不建立业务架构，那么这份需求对我们来说就是一盘沙子，每次我们都要从头把沙子做成砖块，一点点辛苦地开发程序。而建立业务架构的工作，就是要把沙子变成各式各样的零件、部件，从零件做起而不是从沙子做起，像拼图一样，拼出我们的世界来

但这项工作是非常困难的，需要非常深厚的行业知识。并且不是一朝一夕可行，必须通过几个甚至几十个项目的累积，才有可能总结出可用的拼图。然而这份工作又是非常有意义的。作者提出的建议是，在开发项目时，请将业务架构作为项目中的一项工作，它可能不会对你当前的项目带来什么好处，但是，随着每一个项目的积累，不断地修正和丰富业务架构，手中可用的拼图就会越来越多。总有一天，你可以用拼图来完成项目中大部分的业务需求。

拼图，是一个好游戏

10.2.2 现在行动：建立业务架构

实际上建立业务架构的活动非常类似于面向过程的结构化设计，不同的是，在结构化设计方法中，得到的结果是子系统、模块；而在面向对象的设计方法中，得到的结果则是业务构件

业务架构，实际上就是在对需求细致分析和深刻理解的基础上，抽象出若干相对独立的业务模块，形成自洽的业务构件。这些业务构件对内可以完成一个或一组特定的业务功能，对外则有着完善的接口，可以与其他业务构件共同组成更为复杂的业务功能，直至构成整个系统的完整业务功能

上面对业务架构的解释是自底向上的，即业务构件的组合和堆积形成整体业务；但是在建立业务架构的过程中，则是用自顶向下的方法建立的。如何建立业务架构呢？业务用例模型、领域模型和概念模型将帮上我们的大忙

再次回顾一下，业务用例模型为我们解释了业务的细节；领域模型帮助我们为业务的若干问题提供了解决方案；而概念模型则为我们提供了业务骨架的实现和软件架构的实践。三者的结合，就为我们建立业务架构带来了充分的信息

由于需求通常十分庞杂，要从复杂的需求当中找出业务构件并不是一件容易的事，我们很难自信地说我们找到的业务构件能够满足整个业务系统的需求。聪明的办法是从概念模型入手。因为概念模型经过实践，我们有信心说核心业务已经被我们掌握，并且可行性是得到证明的。本章的例子就是以上一节讲述的概念模型为基础，讲述如何自顶向下建立业务架构的过程

实际上图10.11仅仅是图10.2的一个变体而已，并且粒度也很粗，现在还不能说明什么问题。

到这里，业务已经被分解得比较细致了。我们暂时先停下来，姑且认为这就是我们要寻找的构件，先来解决另一个问题。什么问题呢？这些构件并不能形成我们所需要的业务，因为缺少了它们之间如何交互的描述，这个描述在图10.5中体现出来。也就是说，在业务扩充的构件图里，我们还缺少一个构件，这个构件要将其他构件协同起来工作。最终，业务扩充的构件可以用图10.13来表示
我们也可以将抄表台账、计算电费等大的构件分解成适合的业务构件，最终，业务架构也就形成了

上面的例子虽然看上去已经有模有样了，但是我们不能因此高兴过头，因为我们搭建的这个业务架构有可能是错误的。或者它不能完全满足实际的业务需求，或者它根本就是建立在错误的需求理解上，更有可能，在这个供电企业适用，到了另一个供电企业就不适用了。这正是作者说这项工作是非常困难的，需要非常深厚的行业知识。并且不是一朝一夕可行，必须几个甚至几十个项目的累积，才有可能总结出可用的拼图的原因。

但不可否认，如果你的项目一直坚持这样在做，在经过几个项目的积累和不断的修正补充之后，这些构件会越来越完善，最终会为你带来完整的行业解决方案

图10.14是我们在9.5领域建模一节中建立起来的用户档案模型
作为示例，关于管理申请单与用户档案的业务架构建模结果如图10.16所示
经过业务架构的建模工作，我们得到了许许多多的业务构件，它们是我们拼图游戏当中的单元。问题是如何进行拼图呢？虽然我们知道业务构件＋业务构件能够组成更大的业务构件直至整个系统，但是拼图的方法和机制又是什么呢？

答案是软件架构。软件架构要解决的正是如何让拼图们有机地结合在一起工作的问题

如果我们采用J2EE架构，又是一个怎样的情形呢？业务构件的处理逻辑被封装在SessionBean里，而业务实体则被封装在EntityBean里，或者也可以用POJO。当两个业务构件要交互时，一个业务构件通过访问另一个业务构件SessionBean的Remote接口来获得它所需要的数据，以及进行数据交换、逻辑处理等。而这个机制是由J2EE容器来支持的，换句话说，是由J2EE架构来支持的。

如果我们采用SOA架构呢？每个业务构件都被视为一个SCA组件，SCA组件里封装了针对该业务构件的所有允许的操作，而业务实体数据则以BusinessObject的标准形式被封装起来。当两个业务构件要交互时，一个业务构件通过企业总线向另一个业务构件发出SCA消息，另一个业务构件则返回处理的结果。于是两个业务构件得以协作。当我们用另一个更大的SCA组件把两个业务构件封装在一起，共同向外服务时，我们就得到了一个更大的业务构件。而这个机制是由SOA服务器提供支持的，也就是由SOA架构来实现的

业务架构＋软件架构＝业务系统

10.3 系统原型

随着软件规模的扩大和需求的日趋复杂，软件项目非常忌讳的是到了项目的后期才发现问题。问题发现得越晚，项目面临的风险就越大。在项目后期才发现问题时，很多已经完成的工作很可能要返工，不但带来了额外的工作量，质量下降、成本上升都是随之需要面对的问题。更可能遇到的情况是越到后期，距离项目的交付时间越少，项目压力也就越大。此时的项目就像是一座四面漏风的草屋，随时有坍塌的危险了

有许多方法可以尽量避免这些情况的发生，例如事先防范的方法，做更详尽的需求分析、合理的软件过程、评审制度、质量保证机制等；也有快速处理的方法，如敏捷方法。在这些方法中有一种是本章要介绍的，这就是系统原型

什么是系统原型呢？根据用途不同，系统原型也分为好多种，这里做一些简单的介绍。例如，我们可能要使用一个全新的技术或者要面临一个全新的业务需求，为了验证其技术可行性，可能会开发一个小的系统原型，以掌握关键的技术难点并证明我们能够使用这些技术或完成这些新的需求，为后续的开发工作提供第一手实践经验，这是一种验证性原型；如果我们有一个初步的想法，但不知往下能走多远以及这个想法是否可行，也可以开发一个系统原型，以探索这个设想究竟可以走多远，这是一种探索型原型；我们要向客户说明某个产品或概念，为了形象化的演示，让客户有直观的认识，也可以开发一个原型，以显式的方式向客户展示以加深理解，这是一种辅助原型……目的不同，原型也有多种

另一种分类方法是将原型按目的分类，一般有抛弃型系统原型和渐进型系统原型。所谓抛弃型系统原型，就是当原型目的达到后，原型的使命也就结束了。所谓渐进型系统原型，则是在开发原型时，就考虑将来要在它的基础上逐步完善，乃至形成最终系统

只供参考，喜欢请支持正版图书