Net应用软体设计

Net应用软体设计
---- 使用UML
                               周 瑞 & 伟 峰
  
    iO联网组织是一种极柔软的组织形式，层级组织则是一种硬式的组织形式。软体的本质就必须相当“柔软”，与硬体的“刚硬”，构成刚柔并济的最佳拍档。在Internet的基层有TCPIP、HTTP等协定，.Net则提供较高层的软体协定(Protocol)及服务，让软体元件能在Internet上顺利分工整合，支持灵活的跨企业eProcess。
    本文举例说明，如何透过OOAD及UML分析出企业元件(Business Object)，安排这些元件的分工，并整合出企业流程物件(Business Process Object)，也就是use case object (简称uco)；然后再由uco整合出wco (Web Control Object)。而.Net让wco能在Internet上，互相沟通、分工与合作，支持多元多变的eProcess。
  
  

.Net的角色
---- iO软体协定与服务
  
    大家都能感觉东西的「软」与「硬」，例如一条缝衣服的线，你移动线的一头端，不见得会带动线的尾端，所以我们感觉线是软的。而像钢线就感觉硬得多了。日常生活中，还有像泥鳅、龙等都是软的。移动位置是一种「改变」(Change)，龙首改变不会立即强力控制(Control)或影响龙身的改变，对龙尾的立即影响更小。意味着，龙首、龙身、龙尾3个「部份」(Part)之间的相依性(Dependency)蛮小的，构成一个柔软的「整体」(Whole)。

相反地，一条船（如端午节的龙舟）的船头、船身、船尾3部份之间的相依性非常大，构成一个钢硬的「整体」(Whole)。
   钢硬的东西（或系统）各部份直接相依，我们一般会觉得比较容易控制，例如移动船尾就会立即直接影响到船头，改变了方向。
    但是「船舵」就比较特殊了，它跟船尾的相依性不高，移动或转动时并不立即直接影响船尾，却能大幅度间接移动船尾，改变整艘船的方向。

    掌舵者就像抓住龙尾巴，感觉软软的，不太容易控制整条龙。勤加练习、领悟、加上一点艺术美感，才能成为好的掌舵者。
    如果一个系统组织的各部份都类似「舵」这样的独立不太相依的话，整个系统的柔软度就提高了，这样的组织形式就是iO联网组织。反之，如果一个系统组织的各部份都类似「船头」、「船尾」这样的高度相依的话，整个系统的很刚硬，这样的组织形式就不是iO联网组织，而是硬式组织，例如封建官僚的层级组织。
    无论是产业iO、企业iO或软体iO组织，在建构上需要较精致的设计；在管理上也需要较多的艺术美感。虽然需要付出较大成本，但常常可获得巨大的效果。例如轻松转动船舵，就能大幅度改变船的方向。
    从上述的比喻，相信您能体会出软体必须元件化（即iO化）的原因，像船舵就是一艘船里必备的元件。
     再看看，铅笔的例子，古典铅笔是硬式组织，而自动铅笔是软式的iO组织 ---- 笔心、笔身与笔擦，皆是透过介面(Interface)联结，不太相依，能分离换新。
    一般而言，产业愈进步，会设计出愈多的软式产品，也就是元件化产品或系统。例如社会组织由专制独裁到自由法治，电脑硬体由Mainframe到开放式PC组件架构，企业组织由层级组织到无中心组织或iO联网组织。软体产业也是如此，从过去模组式的层级组织到分散式元件软体(Component-based Software)。
    但是软体方面比较特殊的是：应用软体元件含有企业的领域知识(Domain Knowledge)，使得软体元件之结构必须与企业知识结构一致，而且元件内部细节也必须保持高度弹性，随企业规则(Business Rule)而迅速调整，才能随时支持瞬息万变的e企业流程(eProcess)。所以软体iO组织的设计比PC硬体的iO组织，需要更高的分析与设计技巧（如OOAD技术），关于这一点，在本期杂志「台湾软体业的微笑」一文，有详细的叙述，请您阅读之。
    为了支持产业及企业iO化，跨企业的软体系统整合是必要的。传统上，软体系统的整合方式并没有一致的途径，有的透过资料库软体将后端的资料库整合起来，例如资料的复制(Data Replication)软体等。
    也有的依赖中间软体(Middleware)衔接数个不同的App. Server，由各App. Server上软体元件或应用程式互相沟通合作，提供企业整体服务。这种中间软体包括EJB、MTS、MSMQ、MQSeries、Tuxedo、CICS等，如下图1所示。

  

      图1、整合方式：走旧后门
  

    在Internet环境里，家家都有个新门面 ---- Web Server，是标准而开放的大门，具有一致性。今天， .Net提供软体系统的协定及服务，让App Server也能经由别人的新大门，登堂入室，与对方的App Server沟通，如下图2所示。

  

      图2、整合方式：走新前门
  

    上图1的传统整合方式里，后端App Server上的软体系统，常各有专属的介面及资料格式，缺乏一致性，整合工作复杂，执行效率常会降低。例如，一般ERP系统都很难以跟别系统衔接。
    而上图2的Web Server，则具有高度一致性、开放性、标准性，整合工作单纯且高效率。以前，这新大门只供人们透过Browser来查查网页。现在，Internet成为软式组织的连结网主干，而.Net则加强Internet上的协定和服务，让软体元件能分散到各个企业，提供及时完整的资讯到世界各地，成为企业iO组织的稳固基础，也强化跨国界的产业iO组织。其实，这是的EC架构的自然趋势，例如在上一期物件导向杂志(No.13)里，就说明过第三代EC的结构如下图3所示。

  

     图3、第三代EC的基础软体架构（请参阅物件导向杂志No.13）
  

   乍看之下，好象蛮复杂的，其实不然。其基本的组成元素，蛮简单的，只有如下图4所示的几种基本元素而已。wco代表大流程，uco代表小流程，Object或Bean代表企业规则。wco能与其它企业的wco整合出跨企业的流程，提供联合e化服务。当这种整合e化服务愈发达，企业的分工就愈细，也愈专精，也更促进产业的分工整合。


       图4、 .Net应用软体架构的基本元素
  

   在.Net平台上，wco之间可互相沟通，wco与uco之间也能顺畅沟通，如下图5就显示出各种可能的沟通方式。

  

      图5、 .Net应用软体元件的沟通

wco元件之间，wco与uco元件之间，其透过介面衔接，相依性蛮低，所以能极灵活地整合出极柔软的软体，随时支援各式各样的企业流程。
    兹拿MM连锁商店公司为例，MM公司有一个总部(HQ)，上千个分店(POS端）。当您上网向MM公司刷信用卡购物时，MM公司Web Server里的wco元件会请求信用卡银行的wco元件检查顾客资料、信用额度等等。此应用软体的架构如下图6所示：

  

  图6、连锁商店的.Net应用软体元件沟通

从企业内的流程来看，B.O.（Business Object）是分工的工作者，uco则是整合者；从跨企业的e化流程来看，uco是分工的工作者，wco则是整合者。以iO联网组织图来表达上述的分工整合关系，就如下图7所述了。
  

  

   图7、连锁商店的软体iO组织图
  

POS端的元件之间如何沟通，由POS的应用程式协定来决定的。总部的元件之间如何沟通，由总部的应用程式协定来决定的。至于POS端元件与总部元件之沟通则视MM公司的应用软体协定而决定了。例如上图6里的虚线箭头通常是禁止的，以便降低POS端元件设计与总部端元件设计的相依性，可减低软体的开发、管理与维护的成本。但是在某些情况下，则是允许的，这必须在MM公司的应用软体协定中表明清楚。
如果MM公司应用软体协定规则是：只允许POS端的uco元件跟总部的uco元件沟通，而不允许两端的B.O.之间互相沟通。则上图7的iO组织图就相当于下图8了。同时也规定MM公司的uco不能直接与别公司的uco沟通。

  

     图8、连锁商店的另一种软体iO组织图
  

这样的协定，其优点是：子系统之间（例如POS端与总部）的介面简单明确，大大减简化了软体系统的『整体』复杂性。但缺点是：POS端B.O.需要与总部的B.O.沟通时（例如欲更改总部的交易档案资料），须委托uco来转达，徒增了元件内部逻辑的复杂度。如何在这鱼与熊掌的两难之间获取和谐之美，就取决于协定设计者的创意美感了。
   过去的软体开发者，大多基于简单的假设：各个程式的复杂度的总合就是整体系统的复杂度。所以一味追求各个程式的简单化，而忽略掉程式之间介面才是影响整体复杂度的主因。这样子带来的是系统的管理、维护等费用急速上升，像Mainframe上的传统COBOL程式就是个例子。随着现在企业经营环境变动加速，上述软体的管理维护成本更是一路飙涨。
由于元件式软体重视介面的设计，能有下解决这个问题，它才成为当今的主流软体技术。而设计介面（例如子系统介面、元件介面等等），也就成为软体协定设计者的主要工作了，像.Net的主要贡献就是提供一致的元件介面，让软体元件能在网路上顺畅沟通。
为了更清楚说明上述的理念，接下来就拿EC的ShoppingCart为例，从设计.Net应用软体过程中，细嗅它的无限美感。
  
  
  
  
设计 .Net应用软体
---- 以ShoppingCart应用为例
  
兹以EC的ShoppingCart为例说明.Net应用软体设计。依据前面的「软体iO联网组织」文章里所介绍的iO化（即元件化）程序，能从领域知识可找到4个基本概念(Concept)：ShoppingCart、OrderLineItem、Customer及Product。这些概念就对应到软体的元件，以UML的类别(Class)表达元件的定义及元件之间的关系，如下图9：
  
  
  
  图9、以UML类别图表达元件
  
    使用UML的use case图表示系统的功能及动态行为；例如，从ShoppingCart应用系统的user需求来看，此系统应具有如下图10所示的功能或流程：
  
图10、以UML的use case图表达流程
  
在以.Net平台上，上图10的各个use case皆可对应到一个uco元件，uco负责带领ShappingCart等企业物件，以完成该use case的任务。 这些较小use case能组合（或称整合）成为较大use case，例如Web Order wco等，如下图11所示。

  

    图11、ShoppingCart系统的iO联网组织图
  

此MM企业的WebOrder wco元件会委托银行的CreditCard Payment wco元件核验信用卡资料，构成顺畅的跨企业电子流程(eProcess)，强力支持企业的超分工整合。这就是软体iO组织支持企业iO组织的情形。
现在已经了解上图11的各元件之意义了，接下来就看看如何设计MM’s应用软体协定。协定能以中文或英文叙述之，也能以UML语言来表达之。前者比较人性有深刻涵义，后者严谨明确不易混淆。例如可写到：
  
『uco可以呼叫别的uco或B.O. 』
『wco可以呼叫自己公司其他wco
或uco，也可呼叫别公司的wco 』
   ………
  
如果需要更严谨而明确的叙述时，UML就是理想的语言。例如UML的sequence图能细腻地叙述uco与各B.O. 的合作关系。像下图12的UML图就表示Customer与ShoppngCart的分工，由CreateOrder元件将之整合，而达成CreateOrder流程与服务。

  

      图12、 UML表达CreateOrder uco的沟通情形
  

uco元件首先从Customer元件取得顾客资料，例如顾客的交易历史记录、顾客密码等等。此时Customer元件自己会从DB读取顾客资料，然后回传给uco元件。uco核验顾客资料之后，就诞生一个ShoppingCart物件，于是完成了CreateOrder流程的任务了。
同样地，下述的图13以UML语言表示出AddProduct流程里的uco元件与相关B.O.的分工整合情形。首先核验欲购产品的资料，例如库存量等。此时Product元件自己会从DB读取产品资料，回传给ShoppingCart元件。然后ShoppingCart诞生一个OrderLineItem物件，并设定其初期值。
  

  

   图13、AddProduct流程里的分工整合情形
  

   这些UML图不仅规范了uco与B.O.的沟通途径，同时也叙述了B.O. 之间的互相沟通合作。这图并不凸显各元件的程式细节，而是凸显各元件「该有」的服务，以及元件合作关系。

  

图14、RemoveProduct流程里的分工整合情形
  

这些UML图着重元件的沟通介面(Interface)，这就是软体协定的主要内容了。从图14可知ShoppingCart元件的介面里应该包含有RemoveProduct功能。从下图15可知ShoppingCart元件的介面里还应该包含有CalTotal、CalTax、CalSpFee等功能。

  

   图15、CheckOut流程里的分工整合情形


    依序针对每一个uco，皆以UML图叙述该use case的流程，无论流程多么地复杂，UML图皆能表达得很精确。例如下图16就是比较复杂一点的use case。

  

图16、QueryOrder流程里的分工整合情形
  

接着设计wco元件，这wco元件的任务是安排各uco元件的分工合作，能以UML图表示这些uco元件的分工整合情形，如下图17所示。

  

  图17、WebOrder wco代表大流程，由各uco组合而成

这图17说明了wco元件如何与uco沟通，同时也跟银行的CreditCard Payment wco元件沟通合作。
也请留意，上述图12 ~ 16的UML图是应该由App Server的人员负责设计的，这些人员对Web Server技术并不需要深厚的基础。而图17的UML则是由Web Server的人员设计的，这些人员对App Server及DB技术并不需要深厚的基础。这样对开发人员的分工与整合极有帮助。
就App server 元件开发者的观点来看，wco代表Web server，可先开发App server 元件，然后由Web server 的page设计者将wco衔接起来。因之，两者可并行、同步开发，容易衔接整合，且各自弹性成长。
同样地，以UML图表示另一个wco的任务，如下图18所示：
  
图18、WebQuery元件之规画
  
至于Web Page的任务就是安排各wco元件的分工合作，如下图19所示。

  

   图19、Pages安排wco元件的分工整合
  

所以，图12~16是由App Server元件开发者所设计；图17~18是由Web Server元件设计者所绘；图19则由网页规划者所绘制。
各个开发者皆会专精一项，品质提高，学习单纯又快速，当然维护费用也大幅降低。这就是为什么.Net环境的软体生产力将会大幅降低。
  
  
结语
.Net是软体协定，它规范Internet上的软体元件的分工与整合。.Net应用软体架构本质上就是的iO联网组织，是个极柔软的组织。唯有高度柔软弹性的软体才能充分配合Internet天生的柔软和灵活性。
.Net是一般的软体协定，并未规范特定应用领域的软体元件之沟通。所以软体人员除了设计出很棒的软体元件之外，还必须从应用领域里分析与设计出理想的「应用软体协定」，让软体元件能依据特定企业或应用领域的需要而进行美好的分工。而OOAD与UML是协助人们分析元件(角色)、设计协定(剧本)的绝佳利器n