首页专业论文技术应用政策标准解决方案常用资料经验交流教育培训企业技术专家访谈电力期刊
您现在的位置:北极星电力网 > 技术频道 > 常用资料 > 软件设计美学之道(终)──寻找软件美学的迷思与挑战[1]-软件设计美学之道(终)──寻找软件美学的迷思与挑战

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

北极星电力网技术频道    作者:佚名   2008/8/4 18:56:30   

 关键词:  SOA 设计 软件

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

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

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

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

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

  迷思与挑战

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

  学UML等于导入OO?

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

  UseCase与DFD?

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

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

  OO思维与结构化分析?

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

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

[1][2]

来源:希赛网
友情链接
北极星工程招聘网北极星电气招聘网北极星火电招聘网北极星风电招聘网北极星水电招聘网北极星环保招聘网北极星光伏招聘网北极星节能招聘网招标信息分类电子资料百年建筑网PLC编程培训

广告直拨:   媒体合作/投稿:陈女士 13693626116

关于北极星 | 广告服务 | 会员服务 | 媒体报道 | 营销方案 | 成功案例 | 招聘服务 | 加入我们 | 网站地图 | 联系我们 | 排行

京ICP证080169号京ICP备09003304号-2京公网安备11010502034458号电子公告服务专项备案

网络文化经营许可证 [2019] 5229-579号广播电视节目制作经营许可证 (京) 字第13229号出版物经营许可证新出发京批字第直200384号人力资源服务许可证1101052014340号

Copyright © 2022 Bjx.com.cn All Rights Reserved. 北京火山动力网络技术有限公司 版权所有