专栏-成为面向构件的设计师


 2005-09-15 00:00:00       771

第一次认识Architect这个英文单词是源于贝聿铭这个名字,在美国华盛顿现代艺术博 物馆。博物馆令人难忘的现代派风格,与里面的艺术品融为一体,给人亭亭玉立的强烈冲击。所以我第一次成为软件设计师的时候, 心中有说不出的欢喜。然而,软件设计师实际上离Architect相距甚远,倒是更像一个学习素描的学生,面对用户的种种需求 ,用对象一笔一笔的对应翻译。微风吹过,世界发生了变化,用户的需求改了,素描学生看着描了一半的飞鸟不知所措……
也许,随着软件系统越来越大,技术越来 越成熟,我们的软件设计师也能更上层楼,超越(不是抛弃)基于对象的一笔一划,更为宏观地考虑软件系统的架构牢固性、功能实 用性、风格艺术性?
 
软件架构的概念框架
 
我们先来看看什么是软件架构。2000年发布的IEEE 1471标准,给出了架构的概念框架(参见图1)。
图1  IEEE 1471给出的架构的概念框架
 
简单而言,任何系统都是为了某人(Stakeholder)为了某目的(Mission)作某事(Requirement)而建的。系统的内涵就是从不同观点(Viewpoint)用不同模型(Model)来描述的架构(Architecture)。在这里架构就是系统的核心。
 
 
架构牢固性
 
阿基米德说,给我一个支点,我可以撬起整个地球。这句话一语道破了软件架构的根本所在。所谓软件的架构, 就是要用一种很简洁的结构来支撑整个不论大小、可以发展的软件系统。
 
的确,对于架构牢固性而言,架构机制(Architectural Mechanism)是不可或缺的。架构机制为通用问题提供通用解决方案,它即可以是具体的一组类,也可以是抽象 的模式。通常而言,架构机制存在于分层架构的中下层,它对架构的牢固性起到至关重要的作用。架构机制就好比一座大厦的供暖、 供电、排水等系统,解决了整座大厦的不少通用问题。架构机制为系统的其他部分提供行为支持,具体例子有数据库管理机制、事件 通知机制、事务服务机制、权限确认机制等。
 
下面以三种具体架构风格的案例来说明如何获得架构的牢固性。
 
 
●轴辐式架构(Hub&Spoke)。轴辐式架构避免了不同单元直接交互带来的依赖性,使不同单元都与同一个中 心点相连(参见图2),它最大的好处就是松耦合和易扩展。
 
图2 从一锅粥架构到轴辐式架构
 
微软的Win32 API自从1992年发布以来,到今日已有13年了--如此长的产品生命周期,足以让所有软件厂商嫉妒。其实,如此稳固的架 构,其中也不乏轴辐式架构的功劳。先来看看开发者感知到的消息(Message)模型(参见图3)。
图3 基于Win32 API的MFC对消息的支持
 
用户感知到的是“窗口”产生了消息,其实,这都是系统的轴辐架构的功劳(注意,图3不是轴辐架构)。想当年Windows操作系统初火之时,Kernel32.dll、User32.Dll、GDI32.dll这三个动态链接库的重要性几乎无人不知。User32.dll就负责“将中断封装成消息”的重大使命。
 
 
Win32系统只因拥有一个“原始输入信息队列”,不同应用所拥有的窗口的消息,都是通过它“中转”的,所以众多输入设备相关的 驱动软件和不同应用软件直接并无直接耦合关系--这种架构牢固性带来了优秀的可扩展性,无论是新开发的应用,还是新发明的输 入设备的驱动,都可以随时扩展到操作系统平台上来。
 
 
●梁柱式架构。以少量几个柱子为支撑点,发展功能 。比如在一个企业交易系统中,用户管理、用户认证、交易记录等就是这样的基础支柱模块,来承载更多更细的业务流程管理、业务 分析功能。
 
 
 
●公同语言式架构。以统一的共同语言来发展各功能 模块。
 
比如我们可以以关系数据库的统一数据定义为核心,在统一的数据定义上,开发不同发展阶段的企业管理软件模 块和流程。在一个大型的计费软件中,我们可以对计费的原始记录、计费规则、计费记录进行标准化的统一描述,使得各个模块能够 自然的工作在一起。
 
最后,需要说明的一点是,多种架构模式可以结合使用,在架构的不同方面发挥各自的优点。
 
功能实用性
 
IEEE 1471标准里明确提到了系统(System)会有不同的涉众(Stakeholder),可以说负责设计工作的架构师正处在风暴的中心(参见图4)。
图4 架构师须平衡各方需要
 
如果你熟悉面向对象理念,你一定熟悉“抽象”的本质,其实就是抓住重点,忽略其他。当然,折衷思想之中包 含的“木桶原理”哲学,决定了会有不同重要程度的多个重点存在,架构师通过“滑动窗口”的移动而兼顾不同重点。下面就来讨论 一下三个不同的重点:用户视点、过程视点、数据视点。
      
 
 
●用户视点。在IEEE 1471标准里提到了涉众(Stakeholder),而用户是最重要的涉众之一。研究显示,一个产品成功与否,使用起来是否方 便非常重要。从某种意义上讲,用户不会用的功能,等于不存在(其实还要惨,它们把系统搞得更复杂)。为了提高 系统的可用性(Usability),设计师应以用户的经历为考察视点,来组织用户功能。
 
屏幕是可用性设计中最主要的资源之一,它为窗口或页面提供了舞台。当前,窗口和页面的美工设计已经被普遍 关注,下面仅介绍对话图技术。对话图是成熟的软件开发广泛采用的技术,本质上,它是以“窗口”或“页面”为基本要素的状态转 换图,清晰地表达了用户与之直接“对话”的界面的跳转流程(参见图5)。记住,可用性绝不是单个的页面好看,它更深藏在“页面流”所体现的“交互 过程”之中。
 
图5 对话图一例
 
 
●过程视点。注意,笔者这里所谈过程视点,并非 RUP的“进程视图(Process View)”,而是更多地指“业务过程(Business Process)”。在随需应变(On Demand)要求极高的今天,首当其冲的是业务流程的改变。
 
过程视点重视对业务过程的分析,通过建立稳固的模型,来达到支持随需应变的目的;如果变化会更加深入,可 能需要建立元模型。
 
如果说,与美国相比,国内的“行业软件”发展还算可以的话,那么“为软件行业服务的行业软件”却有大量空 白。久而久之,若用“业务”二字指代“软件开发业务”,说不得会令人迷惑良久。鉴于此(也鉴于希望国内软件业全面长足发展之 愿望),我就举个“软件开发业务过程”的案例--假设你在开发Bug管理系统,你需要进行相关的业务过程建模(参见图6)。
图6 为Bug管理“业务过程”建模
 
●数据视点。说到这里,我又要感慨“了解根源”的 重要性了--咦,为什么说“又”呢?因为每每目睹国内追逐潮流的热情与深研技术的冷漠之对比,我都嗟叹不已。
 
数据视点强调以企业的数据为中心,打造长期稳定的企业级系统。对于一些大型应用系统而言,其不断增长的数 据积累就是最重要的资产,比如电信BSS系统、银行OLTP系统、象Wal-Mart之类的零售商的数据仓库系统等。 在这些企业中,数据比应用更具长效性,是独立于任何应用来进行收集、规划、管 理、发展的财富。
 
 
 
风格艺术性
      
我想大家都用过不同品牌的手机。同一代手机的基本功能大致都是一样的。有的手机就像海底捞针一样,把所有 的菜单挖掘一遍,才能找到闹钟的设置。有的手机好像知道你想干啥,你要的功能每每都恰如其时的进入你的手指。
 
确实,当我们软件设计师的眼光离开技术细节,来到宏观的软件架构的时候,我们也从细节的繁琐转移到了整体 的风格。一个好的软件,用起来很自然,就像空气一样,让用户觉得不存在。软件可以是活的,软件可以有个性,软件就是艺术。
 
面向构件的架构
 
圈内的一位朋友曾说,“目前中国的软件开发者整体上处于一种思想困境中,能够讲清楚过去的人很少,能够看 明白未来的人就更少”。笔者深以为然。面向构件与面向对象有很深的渊源(参见图7)。
*        面向对象方法改变了构造应用的方法,却没有改变应用程序 本身的特点。想想看,你用COBOL也好,用C++也好,对用户而言,他们得到的都是一个整体化应用(monolithic application),感觉不到有什么实质性区别。换句话说,面向对象方法是服务于开发人员,而 不是终端用户。
*         分布式系统方法的精华在于考虑到了现实中的分布现状,遵 循了恰当的原理。然而,如何降低开发成本的问题依然悬而未决。
 
图7 面向构件一路走来
 
 
面向构件的设计理念是从更大粒度上来封装独立性较强的业务逻辑,从结构上分解商业应用系统,减少整体复杂 度。最重要的是,在用户眼里软件应用系统发生了变化(当然现在做的还很不够),应用可以按单定做、随需组装。
 
面向构件是一种企业应用软件架构,下面从三个方面分析一下:
●    架构牢固性。面向构件架构的牢固性来自两个方面:一方面 ,开发者感受到的是共同语言式架构,不同构件有着同构的接口,有统一的数据字典,可以组装构件,使整个架构具有可扩展性的好 处。
●    功能实用性。作为构件的功能单元是分层的,利于具体应用 根据不同的“重点权衡”,来选择组装,按单定做。
●    风格艺术性。将解决方案空间分割为构件,并且维护数学的 正交美,其中充满了艺术--而不是有个刻板的标准答案。
 
 
面向构件的设计
 
选择了面向构件的软件平台,软件的架构就有了很厚的基础,软件设计师的工作也更加有规可循:
 
●    提取公用的数据定义。说到这一点,不得不说说领域工程。 软件复用的研究和实践表明,特定领域的软件复用活动相对容易取得成功。领域具有相对稳定性,研究一个领域(而不是研究一个应 用),有助于公用数据的抽取。
 
●    提取支柱性的公用构件、设计扩展构件体系。领域知识可以 分为数据和功能两方面,不仅公用数据应当抽取出来共复用,还应发现公共功能,将之构件化。可以说,面向构件对领域工程的支持 非常自然。
 
●    设计以用户为中心的界面体系。为了保证面向构件设计的成 功,必须重视用户体验。用户界面技术是变化最快的,我们认为应采取如下策略:第一,充分重用现有用户界面Framework,而不是企图提供长期不变的自主开发的Framework;第二,以用户为中心,强调交互设计,提高界面易用性和友好程度。
 
●    以组装方式开发业务流程。不要将业务流程hard-code,否则流程变化时影响过大;而是通过组装构件,提供附加协作逻辑,使业务规则和业务实现分离。

相关阅读: