软件设计美学之道(终)──寻找软件美学的迷思与挑战

如果一个软件公司或软件人，只把自己定位在做小型的商务数据应用项目，那只需要一些简单的结构化分析及编程技术；然而国际上各式软件技术及方法论快速发展，着实希望我们能够跟上国际的脚步，进而发展出自己的价值。

　　技术的演化有其目的与价值

　　从笔者学生时代开始参与软件项目至今，虽然才短短几年时间，在软件设计的技术及方法论上，就已经出现了不少的变化。这从许多贩卖专业计算机书籍的书店就可以略知一二了。虽然现在这些书店的计算机书还是以基础技术实作以及工具使用的书籍为大宗，但是这2、3年来，已经出现了越来越多如Pattern、软件架构、 UML、UP/RUP、Open Source Framework甚至项目管理的相关中文书籍。这种情况代表着计算机书籍的市场，反应出目前业界的问题，也反应出了软件技术演化的需求。

　　相信有许多老手当初在接软件项目时，是从瀑布式流程的方式开始进行。从确定需求，到使用DFD分析客户访谈所得到的数据并归纳出功能列表之后，大致就开始进行SA之后的工作。然后就定期地和客户review进度，并且在每次的review　meeting之后又会有一些修改以及新的功能。周而复始地重复这个梦魇，直到终于上线后，开始祈祷系统短期之内不要有事就好了。

　　以前这种方法，是从客户所要的功能项目开始项目的开发，注重的是输入、输出与数据，很程序性地完成需求，就像是一根根直通通的水管，把水运到目的地就好，不需要真正的OOAD，大不了需要OOP，十分地直觉简单。但是由于技术及软件市场的演化，在台湾开始出现了许多现在大家耳熟能详，诸如这几期的软件美学连载里所提到的技术，我才开始感受到，在我们市侩的项目心态之外，软件设计也有其美学之道的。

　　迷思与挑战

　　在这8篇连载文章里，笔者从对象（Object）技术、Pattern、架构到UP谈起，因为这些东西是习习相关的，我希望能表达出这些技术的完整性。然而在这些不同的主题里，充满了许多常在技术会议或讨论网站上出现的议题，例如，学UML等于导入OO、Use Case与DFD的比较、OO思维与数据思维、再利用迷思、Iterative与Waterfall等等。以下笔者仅针对部分的迷思讨论，提出个人主观的想法。

　　学UML等于导入OO？

　　在之前的篇幅中，笔者都没有提到UML，因为它只是一种提供思维表达的工具之一。虽然有一些在坊间讲相关主题的书籍会以UML的学习做为开埸，不过工具的用途在于被使用，与思维本身没有直接的关系，就像哈利波特的故事可以用许多不都的语言在世界流传一样。UML是用来表达对象观念的绝佳工具，不过，千万不要将导入UML与物件思维画上等号。

　　Use Case与DFD？

　　许多人会拿这两种技术来比较，殊不知这两种技术有着本质及面向上的差异，无论学理或实作，都不应该将他们混为一谈。「Use Case」技术纯粹用来「描述」使用者需求，是以「使用人员」的观点来看他们与系统的互动，它比较接近传统瀑布式流程中SA阶段的「确定需求」步骤。 Use Case Diagram则是用UML来可视化Use Case文件的工具，有点像图像化的需求索引，它不是「Use Case」技术的全部。另外，因为Use Case的观点与客户使用系统的方式一致，因此从Use Case来设计Test Case可以比较容易测试出用户所关心的东西。

　　而DFD是结构化分析中「分析需求」的工具，它是以开发人员的角度来看系统，以数据流为中心，找出相关的程序及数据储存等等，它是瀑布式流程中 SA阶段「确定需求」的下一个步骤。DFD需要有一定程度的客户，才有可能和您一起讨论。当然，与客户的需求确认，Use Case文件或Use Case Diagram，也不见得是与客户确认需求的好方法，端看客户的习惯与能力，有时UI Prototype再加上Functional List就能简单地与客户沟通。

　　OO思维与结构化分析？

　　有人会将DFD当作OOD及OOP的开端，但笔者认为由于对象导向思维与结构化分析在本质上的不同，这样做就像让狗来生蛋一样地奇异。这两种思维，有着截然不同的思考出发点，OO是结合「行为」与「数据」，强调抽象并用对象来呈现概念，而结构化分析则是清楚地将这些东西分开。OOA中包含了对象分析，就是找出并描述领域模型（Domain Model），接下来才有办法完成OOD，因此，怎能把DFD当作OOD的开端呢？物件可不是天上掉下来的礼物啊。

　　OOA中的Domain Modeling是结构化分析不会出现的概念，它也是OOAD中，从「需求」进化到「对象设计层次」中间的重要媒介。在实作上，也有人会把它放到Use Case之前，把它当作整理Use Case的第一步。对于OO的抽象设计来说，Domain Modeling的结果，常会连结到Interfaces（types）而不是实作，这个观念对于领域知识在系统设计上的「再利用」，有着不少的帮助。

　　在实际的软件市场上，有人会说大部份的系统都在使用RDB，而OO无法与关连性数据的思维整合，因此以结构化的分析来设计会好的多。我们先撇开世面上的OR Mapping相关技术不谈，如此的说法没有考虑到OO的「抽象」能力。笔者在这里当然是不建议各位使用OO的方式来设计数据库，因为如果这样做，即使 DBA不跳脚，系统的执行效率也会有问题。这时可以使用Layer的观念替系统设计一个抽象层，用它来连结OO与数据的世界，把对象设计与数据库设计的专业分开。

　　Iterative与Waterfall？

　　不管你喜欢用那一种技术来开发软件项目，都会牵涉到项目进行时的流程，像是UP/RUP和Waterfall。有些人会认为UP/RUP所强调的 Iteration开发方式，不符合台湾的文化国情，所以可能比较适合产品型的项目，而不是一般商业整合型的项目。因为大部份的项目是固定价钱的，使用这种流程会导致成本的增加，因为客户不会另外付费支付多出来的Iteration。不过，在这种情况之下，Waterfall的流程一样也逃不过工期的延长而增加成本的命运，同样的，难道开发产品就可以容许成本的增加吗？因此，这个迷思的重点在于Iteration Plan以及项目管理能力，而不是方法论本身。

　　结语

　　在我们所处的环境中，许多的软件项目是偏向商业的数据库系统，而软件公司的接案心态大多都以系统能在最短的时间结案为重心，不太考虑完整售后客服所需的能量、团队经验的累积，甚至是与世界接轨的机会。至于软件项目的买方，常见的状况则是固定价格及时间，但却有不固定的需求。在如此恶劣的发展环境之下，在国内的软件项目市场里讨论软件美学，的确是充满了迷思与挑战。如果一个软件公司或软件人只把自己定位在做小型的商务数据应用项目，那真的只需要一些简单的结构化分析流程以及编程技术，就够处理大部分的项目。然而国际上的各式软件技术及方法论快速地发展着，笔者着实希望我们能够跟上国际的脚步，进而发展出自己的价值。

原文转自：http://www.ltesting.net