第8章分析之分析类图

墙上挂了根长藤，长藤上面挂铜铃

《长藤挂铜铃》；词：元庸，曲：梅翁，唱：逸敏

在业务建模和需求工作流，我们的思考焦点一直在待开发系统的边界外。现在，思考的焦点从外观过渡到内部机理。

图8-1思考系统的内部机理

系统如何构成，仅仅是软件开发组织考虑的事情，涉众不需要在意——只要系统能满足需求规约里阐明的各种需求。系统为了满足这些需求，必须封装一定的知识。如何组织这些知识，才能让建模人员的大脑更好地把握系统的复杂性，是分析和设计的关键。

8.1.1核心域和非核心域

一个软件系统封装了若干领域的知识，其中一个领域的知识代表了系统的核心竞争力，是系统和其他系统区分的关键所在。这个领域称为"核心域"，其他领域称为"非核心域"。更通俗的说法是"业务"和"技术"，但使用"核心域"和"非核心域"更严谨。[1]核心域不一定是物流、医疗、金融等非计算机领域，也可以是计算机和软件领域。图8-2展示了不同系统的核心域和非核心域概念：

系统

核心域概念

非核心域概念

文档处理器（如MicrosoftWord）

文档、页、行、字……

CStringArray、CFileDialog、MSXML……

电子商务网站（如淘宝网）

商品、订单、会员……

/div、ActionForm、SessionFactory……

图8-2不同系统的核心域、非核心域概念

随着信息化的深入，组织内部封装在软件（即业务实体）中的领域逻辑比例越来越大，深度越来越深，组织之间的竞争越来越依赖于软件的竞争。市场的激烈竞争，又使得组织越来越聚焦于一个领域，为组织提供软件的软件组织也越来越专注于一个领域，甚至逐渐成为组织里的一个部门。将来，独立的软件组织也许将不复存在，或者说，所有组织都是软件组织。从当前的趋势看，软件的运行形态越来越"互联网化"，说"所有组织都是互联网组织"也可以。成熟的"互联网公司"都有自己清晰的领域定位，京东是商场，新浪是媒体……

图8-3软件组织位置的变化

以-年我上门提供服务的组织为例，名字带"软件"、"科技"、"网络"等词语的组织比例已经不到一半，更多的是其他行业组织，例如“***汽车技术有限公司”、“航天**集团第*研究院”、“**市规划国土房产信息中心”、“**飞机设计研究院”、“**银行软件中心”……。

如果软件在组织中的分量不重，关键的领域逻辑还是封装在人脑中，使用一些通用软件就足够了，例如MicrosoftOffice、QQ、微博、。MicrosoftOffice没有为某个行业而定制，医院和北京四中买到的MicrosoftOffice是一样的。如果我们要的不仅仅是"书写文档"的软件，而是要"编写采购计划"的软件，也就是说，软件中要封装"采购计划"的领域逻辑，这就不是MicrosoftOffice能胜任的。[2]这个时候，组织需要的是封装了"采购计划"相关逻辑的"采购业务系统"。

每个组织都有自己独特的"文化"。组织的员工不是标准化的，而是要适合组织的"文化"，这样才有办法在竞争中获胜。引进的软件系统和员工一样，也要体现组织的"文化"，所以不同组织可能还需要不同特色的"采购业务系统"。

综上所述，市场上需要花样繁多的各种系统，这是竞争和分工导致的必然结果。很多系统之间可能在关键的点上有微妙差别，但许多内在机制是类似的。如果能高效复用这些机制，软件组织就能以较低成本变出各种系统来满足市场。

8.1.2基于核心域的复用

"复用"一词实际上没有听起来的那么阳春白雪，设计的目的就是复用。如图8-4所示，软件的开发是动态变化的过程，从第一个功能，到第二个功能……第一个版本，到第二个版本……第一个系统，到第二个系统……。组织发展到一定程度，甚至要维护许多个系统组成的系统家族。设计的好坏之分在于，让已有系统满足新需求时，付出的代价有多大。换句话说，就是以前做的工作可以复用的比例有多高。

图8-4功能→功能集→系统族

有一些"敏捷"论调宣传"开发系统不需要设计，只需要把它分解成小块，一块一块地做就可以了"。按这样的说法，盖大楼也很简单，不需要画图纸，一块砖一块砖往上垒就是。可惜，高下之分就在于：有的团队稳稳地把楼盖上去了，而有的团队在盖第二层时，第一层出问题需要维修，好不容易弄好了，盖第三层时，下面两层又出问题……虽然最终有可能也把楼盖起来，但这样的水平能竞争过别人吗？

软件开发方法的发展史，就是不断提升复用级别的历史。比起很多年以前，现在的软件开发在图形界面、网络协议、数据存取等基础设施领域的复用上，已经达到了相当的高度。例如要做图8-5这样的一个点名抽奖工具，需要人工编辑的介质（即所谓"源代码"）只需要几十行字符，其它部分的逻辑已经由基础设施封装了。

图8-5基础设施的复用已经到了一定高度

遗憾的是，目前大多数软件组织的复用仅停留在基础设施领域的复用，即使有自己的"内部开发平台"，也仅是根据自己所开发系统的需要对基础设施作进一步封装。特别是"互联网公司"，其津津乐道的"架构"往往就是基础设施的架构。

在一些软件开发大会常可以看到这样的场景：某电子商务网站的架构师上台讲了一通，接着某视频网站的架构师上台也讲了一通，咦，两个演讲内容如此相似？原来，他们讲的都是自己系统中非核心域的知识，根本不涉及核心域的知识。究其原因也许并非不为，而是不能——开发人员对自己所开发系统的核心域研究太浅。许多“网红程序员”在网上谈论的内容大多是某种语言或框架的新特性，少有探讨他当前所开发系统的复杂领域逻辑，也是同样的原因：并非不为，而是不能。

非核心域（也就是别人的核心域）的优势仅仅是暂时的，竞争对手也能通过同样的渠道获得。A采用了某种新的工具，短时间内获得了对B的竞争优势，但随后B也获得了该工具，A的竞争优势很快就消失了，利润流进了工具厂商的口袋。非核心域的改进是必要的，但不充分，还要在核心域上深入挖掘，让竞争对手无法轻易从第三方获得。对于软件组织来说，在核心域上深入挖掘，达到基于核心域的复用，是获得和保持竞争力的根本手段。

对软件开发组织里的个人来说，专注于某个核心域也越来越重要。过去说“我是一名Java程序员，我可以用Java来开发物流系统、保险系统、医院系统”，现在要说“我是一名物流领域的开发人员，擅长用Java实现”。

要做到这一点基于核心域的复用，有一定的难度，因为能带来利润的系统，往往被迫的领域比较多，"负载"比较高。

开发一个基础设施领域的系统，例如操作系统，只需要计算机的资源，不需要顾客、订单、病历等具体某个应用领域的概念。按道理，开发应用系统也应该可以不管基础设施，但遗憾的是，当前现实中大多数情况下还是要管。例如，开发一个"棒医生在线"网站，不仅仅需要具备医疗卫生领域知识，还需要懂Linux，懂MySQL，懂Apache……。

另外，基础设施领域有大量已出版教材和先行例子，高校也为计算机和软件相关专业学生开设了相应课程（LinusTorvalds就是在大学教材中MINIX案例的激发下编写了Linux）。这样，开发人员的大脑比较容易把握基础设施领域的复杂性，对显式建模的要求没有那么高。在年2月1日用"操作系统"为关键字搜索当当网（dangdang.







































儿童白癜风病的症状
第一家白癜风医院

转载请注明原文网址：http://www.imeimeishou.com/tbyy/8006.html