CSDN博客

img dwater

UMLChina上海公开课听课体会

发表于2004/5/7 22:17:00  1878人阅读

UMLChina上海公开课听课体会

9月下旬,UMLChina首席专家think在上海开设了一次主题为“UML应用实作细节”的公开课。在为期两天的课程中,他主要讲演一种应用UML进行OOAD的软件开发过程,该过程将软件开发划分为多次迭代,每次迭代包含以下几个主要步骤:

第一步,捕获系统需求,得到用例图和有价值的需求文档;

第二步,从用例文档捕获实体类,得到类图;

第三步,使用顺序图,为类分配职责。

第四步,针对具体平台进行设计,精化前面得到的类图和顺序图。

此后可很容易得到系统架构,并将设计结果转化为代码。不失完整性,不妨加上第零步:业务建模。该过程体现了敏捷建模的原则,紧抓UML中最重要的东西,在必要的时候考虑加入其他元素。结合这些天在项目中的实践情况,谈几点主要的体会。

一、              构建软件,最困难的是需求的捕获。

开发软件,到底最困难的地方在哪里?布鲁克斯(《人月神话》作者)在他那篇著名的论文《没有银弹》中说的很清楚:构建软件系统,最困难的部分就是精确决定到底构建什么。业界专家也告诉我们需求是变化的,不明确的,甚至是误导的。在这两天的课程中,think把一天多的时间花在用例身上,正确捕获需求的困难,由此亦可略见一斑。

我个人对需求捕获的困难也深有体会。在以前的公司,老板经常会跑到办公室里描述客户新的、变化的愿望,我们开发人员只能硬着头皮去修改软件,使之适应变化、包含新的功能。其时此时我们并不清楚客户真正需要什么,又或者说客户自己都不清楚自己想要什么。最怕的是折腾了几个星期后,老板说客户还是喜欢我们从前的软件。我们其实什么都不用做!来到DT注:作者所在公司)后,由于自己不是通信专业出身,很多业务上的问题都需要不断地向同事请教,并查阅一些相关的资料,否则就无法进行分析设计。

既然需求捕获是最困难的,那么从风险的角度来看,它也应该是最重要的。我们除了在思想上愿意为需求付出相应的代价以外,还应该在行动上以一种正确的方式去捕获需求。

首先,应该有正确的需求队伍,即用户+业务专家+开发人员。从本质上来讲,需求是用户的需求,应该体现用户的价值,而不能是开发方的想当然和一厢情愿,做商业软件尤其应该明确这一点。不能为客户创造价值的软件,那将不能成为商品,最多只能成为自己的玩具。对付需求风险最重要的要素之一是熟悉领域的专业知识,不接近领域专家是项目失败最常见的原因之一。

其次,应该立足用户视角去看待问题,并以一种合理的结构去记录需求结果,这样才能够有效应对需求的困难和易变。很显然,开发人员喜欢站在自己的立场去考虑问题,这种习惯体现在需求中往往是“系统做什么”,而根本没有“用户做什么”,“用户希望系统做什么”。开发人员喜欢那些具体的概念,如“下拉菜单”、“OK按钮”,而这些东西往往最易变化,最难维护。

UE应用软件小组在前期是以用例来捕获需求的,在此期间出现过很多很多的争议,现在回过头,我想对用例的使用的要点做如下总结:

1.  把用例和参与者的目标连接在一起;

2.  将基本流和可选流分开;

3.  不要把步骤当用例;

4.  将设计说明排除在用例之外;

5.  界面设计是设计,是脆弱易变的,不应该被包含在用例文档中。

需求不清楚,目标不明确,软件开发是打移动靶,还是南辕北辙,时间和竞争对手会给出答案。

二、              使用UML建模,最重要的是问自己,如何向下指导生成代码。

使用UML的基本理由之一是交流,它既保留一定程度的精确性,又不失细节。UML还可以帮助人们迅速获知系统全貌。这一点可能很多人都有所体会,但是不要忘了,在使用UML建模时问问自己为什么要这么做,以及如何用它向下指导生成代码。

早期的软件开发,其错误认识和做法主要表现为忽视软件需求分析的重要性,轻视软件维护,认为软件开发就是写程序并设法使之运行。软件危机的出现让人们意识到项目管理的重要,意识到需求、分析、文档的重要,但同时也导致另一场灾难,即为了文档而文档,为了建模而建模,而忘记了软件开发的最终目的:交付有价值的软件(再往前一步,事实上大部分就是交给编译器的东西——代码)。个人认为,软件开发过程中的一切活动都应该服务于这个目的,否则将只是浪费精力,贻误商机。

看看我们如何用前文所述的方法来指导代码的生成:

我们知道,在OO程序中任何事物都是对象,OO程序的运作就是一系列对象的诞生、死亡,以及对象彼此间的通信。OO将所有对象分成各种对象类,每个对象类定义一组属性和方法。因此OOAD很大程度上就是要找出这些类,为它们定义合理的属性和方法,也就是产生合理粒度的类。其实很多OO新手最大的问题就在这里,一个类包容一切,导致软件的呆板、脆弱、难理解、难以维护、不可复用。

回到上述开发过程。第一步我们将得到好的用例文档,它在一定程度上描述了用户如果使用系统、系统如何响应用户要求以实现用户目标;通过抽取该文档中的名词,经过快速、细致的分析,我们可在第二步得到大多数重要的类,并初步确定类的属性;在第三步,使用顺序图来描述各个对象间如何交互以实现用例,为各个类分配职责,这便可以初步确定类的方法;在此之前得到的结果都是平台无关的,我们可在第四步通过结合具体的平台进行设计,对前面的得到的类进行进一步的精化,此后便可方便的将设计结果转化为代码。

在第三步使用顺序图为类分配职责时应该遵循一个总的原则:低耦合、高内聚。具体地说,应该遵守以下几条原则:

1.  专家原则。把职责分配给信息专家,即那些有足够资源来承担该责任的类。

2.  老板原则。在B聚合或组合A时,发给A的消息应先通过B处理和中转。

3.  可视原则。不要和陌生人说话,两个对象之间有消息交互,相应类之间应该有关联。

三、              使用UML,形势正确容易,内容正确难。

UMLOO在国内也算是风光过好一阵子了,说起来大家都在使用UML,都在OOAD,但真正取得了理想成果的团队好像并不太多。为什么会如此?我很赞同Think的说法:形式正确容易,内容正确难。就拿用例来说,好像大家都是在捕获需求,但是如果包含了太多的细节,那么用例文档就不得不经常的变更,因为细节是容易变的,文档必须和他们同步;如果过分地细化用例,那么必然会犯上将步骤当用例的毛病,这样的“用例”将无法实现用户的一个完整目标,无法为用户创建价值,也便违背了用例的初衷。所以说,对于UML的学习,除了其形式上的东西,还应该多多思考,掌握表面下面的东西。

如果说用例体现了用户的目标,那么其中每一个步骤都应该向这个目标迈进;如果说软件开发是一个问题域到解域的求解过程的话,那么在开发周期中的每一个活动都应该向解域迈进。就像我们从前解方程,不管其中有多少过程,其目的都是为了最终那个结果,阅卷人不会因为你在其中说了半天的废话而给你加上半分;软件开发也是如此,客户也不会因为你在其中走了多少弯路而多掏半分钱给你。过多的形式上的东西,好看不中用的东西,不是自我折磨,便是自我安慰。

说到底,UML本质上是建模语言,其根本目的是辅助求解。简单的、实用的、对求解有帮助的内容,能够帮助开发人员向下生成代码的内容,才是正确的内容。

                                                                                                         2003-11-16

参考书籍:

Steve Adolph, Paul Bramble. 有效用例模式

0 0

相关博文

我的热门文章

img
取 消
img