呼唤架构设计的多重视图方?/strong>
灉|一闪，想Z(jin)把大象放q冰q办法Q这自然好。但希望每个架构设计{略都依靠灵感是不现实的--我们需要系l方法的指导?/p>
需要架构设计的多重视图Ҏ(gu)Q从Ҏ(gu)上来说是因ؓ(f)需求种cȝ复杂性所致。以工程领域的例子开道吧。比如设计一座跨江大桥：(x)我们?x)考虑"q接南北的公路交?q个"功能需?Q从而初步设计出理想化的桥墩支撑的公路桥Ҏ(gu)Q然后还要考虑造桥要面临的"U束条g"Q这个约束条件可能是"不能影响万吨轮从桥下通过"Q于是细化设计方案，规定桥墩的高度和桥墩之间的间距；另外q要֏(qing)"大桥的用期质量属?Q比如ؓ(f)?能在湍急的江流中保持稳?Q可以把大桥桥墩深深地徏在岩矛_之上Q和大地然一体；其实Q?建造期间的质量属?也很值得考虑Q比如在大桥的设计过E中考虑"施工方便?的一些措施?/p>
和工E领域的功能需求、约束条件、用期质量属性、徏造期间的质量属性等cMQY件系l的需求种cM相当复杂Q具体分cd?所C?/p>
? 软g需求分cȝ复杂?/strong>
市(jng)pȝ案例Q理解需求种cȝ复杂?/font>
例子是最好的老师。ؓ(f)?jin)更好地理解软g需求种cȝ复杂性，我们来分析一个实际的例子。在?中，我们列D?jin)一个典型的市(jng)pȝ的需求子集，从这个例子中可以清晰地看到需求可以分Z大类Q功能需求和非功能需求?/p>
? 市(jng)pȝ案例Q理解需求种cȝ复杂?/strong>
单而言Q功能需求就?软g有什么用QY仉要做什?。同Ӟ注意把握功能需求的层次性是软g需求的最?jng)_c(din)以该超?jng)系lؓ(f)例：(x)
* 市(jng)老板希望通过软g?提高攉效率"?br /> * 那么Q你可能需要ؓ(f)攉员提供一pd功能来促(j)成这个目的，比如供收银员使用?L商品可单独取消"功能有利于提供收银效率（W者曾在超?jng)有q被q整单取消然后一车商品重新扫描收费的痛苦l历Q?br /> * 而具体到q个市(jng)pȝQ系l分析员可能?x)决定要提供的具体功能?f)Q通过攉l端的按键组合，可以使收银过E从"逐项录入状?q入"选择取消状?Q从而取消某商品?
从上面的例子中我们还惊讶地发玎ͼ非功能需?-Z最l常忽视的一大类需?-包括的内定w常宽、ƈ且极光要。非功能需求又可以分ؓ(f)如下三类Q?/p> * U束。要开发出用户满意的Y件ƈ不是件容易的事，而全面理解要设计的Y件系l所面(f)的约束可以你向成功q进一步。约束性需求既包括企业U的商业考虑Q例?目预算有限"Q，也包括最l用L(fng)的实际情况（例如"用户的^均电(sh)脑操作水q_?Q；既可能包括具体技术的明确要求Q例?要求能在Linux上运?Q，又可能需要考虑开发团队的真实状况Q例?开发h员分散在不同地点"Q。这些约束性需求当然对架构设计影响很大Q比如受?目预算有限"的限Ӟ架构师就不应选择昂贵的技术或中间件等Q而考虑到开发h员分散在不同地点"Q就更应注重软g模块职责划分的合理性、松耦合性等{?br /> * q行期质量属性。这c需求主要指软gpȝ在运行期间表现出的质量水q뀂运行期质量属性非常关键，因ؓ(f)它们直接影响着客户对Y件系l的满意度，大多数客户也不会(x)接受q行期质量属性拙劣的软gpȝ。常见的q行期质量属性包括Y件系l的易用性、性能、可伸羃性、持l可用性、鲁性、安全性等。在我们的超?jng)系l的案例中，用户寚w性能提出?jin)具体要求（真正的性能需求应该量化，我们的表1没体玎ͼ(j)Q他们不能容忍金额合计超q?2U的延时?br /> * 开发期质量属性。这c非功能需求中的某些项Z倒是念念不忘Q可惜很多hq没有意识到"开发期质量属?? q行期质量属?Ҏ(gu)构设计的影响到底有何不同。开发期质量属性是开发h员最为关?j)的Q要辑ֈ怎样的目标应Ҏ(gu)目的具体情况而定Q而过度设计（overengineeringQ会(x)p额外的代仗?
什么是软g架构视图
那么Q什么是软g架构视图呢？Philippe Kruchten在其著作《Rationall一q程引论》中写道Q?/p>
一个架构视图是对于从某一视角或某一点上看到的系l所做的化描qͼ描述中涵盖了(jin)pȝ的某一特定斚wQ而省略了(jin)于此斚w无关的实体?/p>
也就是说Q架构要늛的内容和决策太多?jin)，过了(jin)h?一y而就"的能力范_(d)因此采用"分而治?的办法从不同视角分别设计Q同Ӟ也ؓ(f)软g架构的理解、交和归档提供?jin)方ѝ?/p>
值得特别说明的，大多Cc中都强调多视图Ҏ(gu)是Y件架构归档的Ҏ(gu)Q其实不然。多视图Ҏ(gu)不仅仅是架构归档技术，更是指导我们q行架构设计的思维Ҏ(gu)?/p>
Philippe Kruchten提出?+1视图Ҏ(gu)
1995q_(d)Philippe Kruchten在《IEEE Software》上发表?jin)题为《The 4+1 View Model of Architecture》的论文Q引起了(jin)业界的极大关注，q最l被RUP采纳。如?所C?/p>
? Philippe Kruchten提出?+1视图Ҏ(gu)
该方法的不同架构视图承蝲不同的架构设计决{，支持不同的目标和用途：(x)
* 逻辑视图Q当采用面向对象的设计方法时Q逻辑视图卛_象模型?br /> * 开发视图：(x)描述软g在开发环境下的静(rn)态组l?br /> * 处理视图Q描q系l的q发和同步方面的设计?br /> * 物理视图Q描qY件如何映到gQ反映系l在分布斚w的设计?
q用4+1视图Ҏ(gu)Q针对不同需求进行架构设?
如前文所qͼ要开发出用户满意的Y件ƈ不是件容易的事，软g架构师必d面把握各U各L(fng)需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满?/p>
Philippe Kruchten提出?+1视图Ҏ(gu)Y件架构师"一一征服需?提供?jin)良好基Q如?所C?/p>
? q用4+1视图Ҏ(gu)针对不同需求进行架构设?/strong>
逻辑视图。逻辑视图x功能Q不仅包括用户可见的功能Q还包括为实现用户功能而必L供的"辅助功能模块"Q它们可能是逻辑层、功能模块等?/p>
开发视图。开发视囑օ注程序包Q不仅包括要~写的源E序Q还包括可以直接使用的第三方SDK和现成框架、类库，以及(qing)开发的pȝ运行于其上的系lY件或中间件。开发视囑֒逻辑视图之间可能存在一定的映射关系Q比如逻辑层一般会(x)映射到多个程序包{?/p>
处理视图。处理视囑օ注进E、线E、对象等q行时概念，以及(qing)相关的ƈ发、同步、通信{问题。处理视囑֒开发视囄关系Q开发视图一般偏重程序包在编译时期的?rn)态依赖关p，而这些程序运行v来之后会(x)表现为对象、线E、进E，处理视图比较x的正是这些运行时单元的交互问题?/p>
物理视图。物理视囑օ?目标E序?qing)其依赖的运行库和系lY?最l如何安装或部v到物理机器，以及(qing)如何部v机器和网l来配合软gpȝ的可靠性、可伸羃性等要求。物理视囑֒处理视图的关p：(x)处理视图特别x目标E序的动态执行情况，而物理视N视目标程序的?rn)态位|问题；物理视图是综合考虑软gpȝ和整个ITpȝ怺影响的架构视图?/p>
讑֤调试pȝ案例概述
本文的以下部分，研I一个案例：(x)某型可备调试系l?/p>
讑֤调试员通过使用该系l，可以察看讑֤状态（讑֤的状态信息由专用的数据采集器实时采集Q、发送调试命令。该pȝ的用例图如图4所C?/p>
? 讑֤调试pȝ的用例图
l过研制方和委托方的紧密配合Q最l确定的需求可以L地用?来表C?/p>
? 讑֤调试pȝ的需?/strong>
下面q用RUP推荐?+1视图Ҏ(gu)Q从不同视图q行架构设计Q来分门别类地将不同需求一一满?/p>
逻辑视图Q设计满_能需求的架构
首先Ҏ(gu)功能需求进行初步设计，q行大粒度的职责划分。如?所C?/p> * 应用层负责设备状态的昄Qƈ提供模拟控制C用户发送调试命令?br /> * 应用层用通讯层和嵌入层进行交互，但应用层不知道通讯的细节?br /> * 通讯层负责在RS232协议之上实现一套专用的"应用协议"?br /> * 当应用层发送来包含调试指o(h)的协议包Q由通讯层负责按RS232协议之传递给嵌入层?br /> * 当嵌入层发送来原始数据Q由通讯层将之解释成应用协议包发送给应用层?br /> * 嵌入层负责对调试讑֤的具体控Ӟ以及(qing)高频度地从数据采集器d讑֤状态数据?br /> * 讑֤控制指o(h)的物理规D装在嵌入层内部Q读取数采器的具体细节也被封装在嵌入层内部?
? 讑֤调试pȝ架构的逻辑视图
开发视图：(x)设计满开发期质量属性的架构
软g架构的开发视囑ֺ当ؓ(f)开发h员提供切实的指导。Q何媄(jing)响全局的设计决{都应由架构设计来完成，q些决策如果"?C(jin)后边Q最l到?jin)大规模q行开发阶D|发现Q可能造成"E序员碰头儿临时军_"的情况大量出玎ͼ软g质量必然下降甚臛_致项目失败?/p>
其中Q采用哪些现成框架、哪些第三方SDK、乃臛_些中间gq_Q都应该考虑是否pY件架构的开发视囄定下来。图6展示?jin)设备调试系l的Q一部分QY件架构开发视图：(x)应用层将ZMFC设计实现Q而通讯层采用了(jin)某串口通讯的第三方SDK?/p>
? 讑֤调试pȝ架构的开发视?/strong>
在说说约束性需求。约束应该是每个架构视图都应该关注和遵守的一些设计限制。例如，考虑?一部分开发h员没有嵌入式开发经?q条U束情况Q架构师有必要明说明系l的目标E序是如何编译而来的：(x)?展示?jin)整个系l的桌面部分的目标程序pc-moduel.exe、以?qing)嵌入式模块rom- module.hex是如何编译而来的。这个全局性的描述无疑Ҏ(gu)有经验的开发h员提供了(jin)实感Q利于更全面地理解系l的软g架构?/p>
? 讑֤调试pȝ架构的开发视?/strong>
处理视图Q设计满行期质量属性的架构
性能是Y件系l运行期间所表现出的一U质量水qI一般用pȝ响应旉和系l吞吐量来衡量。ؓ(f)?jin)达到高性能的要求，软g架构师应当针对Y件的q行时情况进行分析与设计Q这是我们所谓的软g架构的处理视囄目标。处理视囑օ注进E、线E、对象等q行时概念，以及(qing)相关的ƈ发、同步、通信{问题。图8展示?jin)设备调试系l架构的处理视图?/p>
可以看出Q架构师Z(jin)满高性能需求，采用?jin)多U程的设计：(x)
* 应用层中的线E代表主E序的运行，它直接利用了(jin)MFC的主H口U程。无论是用户交互Q还是串口的数据到达Q均采取异步事g的方式处理，杜绝?jin)Q?忙等?无谓的耗时Q也~短?jin)系l响应时间?br /> * 通讯层有独立的线E控制着"上上下下"的数据，q设|了(jin)数据~冲区，使数据的接收和数据的处理相对独立Q从而数据接收不?x)因暂时的处理忙而停滞，增加?jin)系l吞吐量?br /> * 嵌入层的设计中，分别通过旉中断和RS232口中断来Ȁ发相应的处理逻辑Q达到轮询和收发数据的目的?
? 讑֤调试pȝ架构的处理视?/strong>
物理视图Q和部v相关的架构决{?/strong>
软g最l要ȝ、安装或部v到硬件才能运行，而Y件架构的物理视图x"目标E序?qing)其依赖的运行库和系lY?最l如何安装或部v到物理机器，以及(qing)如何部v机器和网l来配合软gpȝ的可靠性、可伸羃性等要求。图9所C的物理架构视图表达?jin)设备调试系lY件和g的映关pR可以看出，嵌入部分ȝ在调试机中（调试机是专用单板机）(j)Q而PCZ是常见的桌面可执行程序的形式?/p>
? 讑֤调试pȝ架构的物理视?/strong>
我们q可能根据具体情늚需要，通过物理架构视图更明地表达具体目标模块?qing)其通讯l构Q如?0所C?/p>
?0 讑֤调试pȝ架构的物理视?/strong>
结与说?/font>
所谓本立道生。深入理解Y仉求分cȝ复杂性，明确区分功能需求、约束、运行期质量属性、开发期质量属性等不同U类的需求就??Q因为各c需求对架构设计的媄(jing)响截然不同。本文通过具体案例的分析，展示?jin)如何通过RUP?+1视图Ҏ(gu)Q针对不同需求进行架构设计，从而确保重要的需求一一被满?/p>
本文重点在于Ҏ(gu)的解_(d)因此省略?jin)对架构设计中不具体问题的说明Q同时本文提供的说明架构设计Ҏ(gu)的模型也l过?jin)简化。请读者注意?br />
本文来自Q?a >http://www.uml.org.cn/SoftWareProcess/200607315.htm
]]>