BlogJava-每日一得-随笔分类-建模

真正理解面向接口编程

Alex — Sun, 11 Mar 2007 16:40:00 GMT

摘要: 阅读全文

Alex 2007-03-12 00:40 发表评论

powerdesigner中外建问题

Alex — Wed, 31 Jan 2007 02:42:00 GMT

key words: pd, powerdesigner,外建

在PD中建立外键碰到一个问题，如: forum(id,name)表，forum_thread(id,forum_id)表，需要将forum的id设为forum_thread的外建，指向forum_id,默认的在 PD中是将主键设为外建.

需要如下设置才可以:

Alex 2007-01-31 10:42 发表评论

[zt]一个软件设计的全过程(基于UML)

Alex — Fri, 22 Sep 2006 05:16:00 GMT

key words:软件设计建模 UML

这篇文章以前就看到了，后来再想看的时候居然找不到了，感觉写的不错，作为想把软件开发往深里整地朋友有借鉴作用。

转自这里

前段时间把一个界面框架完成了，今天基于这个框架开发一个小模块，在这里把这个模块设计的全过程记录下来，希望大家讨论并指正。

一、起因

公司交给我一个任务，为测试员写一个手机模拟界面，以方便她们的手机短信测试。过去她们都是用MC4J直接调用公司服务器的MBean服务来模拟进行测试，以验证我们整个系统平台。这种测试主要是检查收发短信是否正常，而我的要做的工作就是，让她们在测试的时候更方便更直观。

二、需求

我和测试员陈MM（也就是软件的使用者）约定了一个时间，大家一起来讨论这个软件的需求。

1、首先，我大概了解了一下她们的测试工作，知道我要做个什么东东。

2、然后我回去思考了一下，再次找她详细了解其测试的具体步骤，并在一张白纸上以UML用例图的方式，记录下需求的功能。用例是什么？用例就是需求，就是你的软件应该具有的功能，当然用例图只是概括性的对功能进行了描述。

3、最后，我坐在我的电脑前开始用MagicDraw UML来画用例图（我不喜欢用Rose，那玩意太笨重了，界面友好性也不好）。在画用例图的时候，我发现了一些隐含的功能，这些是陈MM在和我做需求时没有考虑到的（注：开发者应该为用户挖掘隐含需求）。我和陈MM一一确定了这些我新发现的需求，最后得到如下的用例图。

（1）手机前台测试操作的用例图（说明：include是指某用例包含(include)子用例）

（2）后台管理

三、界面设计

接下来是界面设计。既然是手机模拟，我很自然就拿我的motorola手机的操作界面来做参考。不过这里应该注意到，手机操作环境和电脑操作环境不尽相同（比如说电脑有鼠标，还有键盘可以输入文字），所以没有必要唯妙唯肖的完全模枋，还是以使用者操作方便为主。

界面设计是很重要的一步，不要一上来就写程序，一定要先做到心中有个大概，否则返工的可能性就很大。而且，把界面拿出来给客户看，客户也就能做到心中有数，还能尽早提出一些新需求和意见来。千万不要等到软件做完了再拿给客户看，到时客户看了如果要修改，那就做太多白费工了。

由于软件界面相对简单，陈ＭＭ基本没有提修改意见，但这不是个好兆头。不过极限编程就是要拥抱变化不是^_^。咱不怕她改，只要大致的界面她能定下来就行了。

界面我喜欢用Visio来画，当然也听说有人喜欢用ＶＢ来快速构建界面原型的，看个人喜好了。整个界面如下：

这个是后台管理界面

四、类图

类图反映了软件的数据模型。在设计数据模型，我参考了界面设计图和用例图，找出一个个的类。然后参照用例图的一个个功能，设计出了各类的属性和方法。设计初始的类图当然不可能很详细，但至少应该看到个大概。有错误不要紧，后期可以慢慢修正，但大体关系就算定下来了。

Neil（公司ＣＴＯ，一个40岁左右的真正的资深程序员）说：看一个软件的设计主要看两个类：类图和时序图。类图确定了软件数据模型的静态关型，时序图则是数据模型的动态关系。

类图如下，看英文大致可以知道类／属性／方法的含义和作用了，就不一一介绍了。

五、时序图

时序图是本文最后一个图，时序图表明了用例图中各功能的实现方案，同时也反应了类图中各类的交互关系。以后程序的逻辑和时序图基本一致。不过，有些人会去画得很详细的时序图，详细到都快赶上伪代码级别了，我觉得这没必要。我把时序图看做反映自己思路的大概过程，所以也就画个大概。

我认为时序图要简洁易懂，这样以后你的后继维护者，拿到这个软件的时序图（当然也包括用例图、类图），就能明白你的大概设计思路。另外，画时序图也能整理自己的思路，同时还可以对类图的设计进行验证。在画这个时序图的过程中，我就纠正了在类图中的几处考虑不周的地方。

总结：时序图可以（１）整理思路（２）验证类的设计（３）是很好的软件文档，对维护者理解代码很有帮助。

这里仅给出其中几个时序图（实际上我也没有把用例都画完，有些类似的简单的，就忽略了）

（１）新增一个手机号码

（２）关机

（３）开机

（４）发送短信

到这里设计阶段就完成了，用时一天。下一步是编码，将应用ＴＤＤ先写测试代码的方式来写代码，下次再介绍了。

作者简介

陈刚，广西桂林人，著作有《Eclipse从入门到精通》
您可以通过其博客了解更多信息和文章：http://www.ChenGang.com.cn
版权声明：本博客所有文章仅适用于非商业性转载，并请在转载时注明出处及作者的署名。

Alex 2006-09-22 13:16 发表评论

[zt]领域相关的模型里面需要3种对象

Alex — Wed, 20 Sep 2006 01:53:00 GMT

转自portian

基本上一个应用程序里面的领域相关的模型里面需要3种对象：
1。值对象(Value Object)，没有身份，内容表示一切，譬如我和weihello都去银行里面存取100大洋，那这个100RMB是一个值对象

2。实体对象（Entity)，需要持久，不是按照内容，而是按照它的身份来区分，也就是说即使内容完全一样，也不是同一个对象。这个身份在内存里面是它的实例地址，在数据库里面是关键字，最常见的就是OID.这个实体对象并不是纯数据，它处理本身的实体模型，例如Accout，它的 withDraw,它的子Account等等，它也处理自己和其他实体对象之间的关系，例如订单里面的订单行，都是应该在这个Account里面实现的，而不应该有一个什么控制类。在一个Web应用程序里面，涉及到对象关系的一般只需要一个（或几个）DTOFactory负责所有对象的DTO和 Entity之间的组装和拆份，不需要专门的管理，这一部分也是和数据建模最相近的地方。

3。服务对象(Service)，这是为我们提供服务的类，譬如银行里面服务员，她帮助我们把钱从一个账户转到另外一个账户，并记录相应的交易。

对象的作用是对它自己的内部状态负责，如果它需要存取很多其它对象的状态进行运算，那叫做特性忌妒，是要重构的。应该把这些代码移到那个持有这些状态的类里面

辨别一些名词：
1。VO：实际上很模糊，通常指ValueObject和ViewObject
2. ViewObject，界面展现需要的对象，如Struts的FormBean
3。Value Object，早期被作为ValueObject和Transfer Object的总称。实际上Value Object的真正意义在于它的内容，而不是身份
4。Transfer Object：数据传输对象，在应用程序不同层次之间传书对象，在一个分布式应用程序中，通常可以提高整体的性能
5。PO：也许就是Persistent Object，基本上就是Entity了
在不同的体系结构和实现方式里面，这些对象有可能重复，也有可能不重叠。如果你要做一个对所有的体系都能够方便移植的框架，那么每一种对象都需要严格区分。例如JDO的PO不能作为TO，应为它不能脱离PM，譬如你可以选择用ViewObject（如Struts的FOrmBean)直接作为 TO，但在tapestry和Webwork里面就不合适了。但在很多时候，能够方便实用是最重要的，不要过度设计就是了。

Alex 2006-09-20 09:53 发表评论

[zt]做设计的步骤

Alex — Wed, 20 Sep 2006 01:02:00 GMT

key words: 如何做设计设计步骤
转自robin

一。需求分析(抽象Use case + 分析Use case之间的关系)

分析软件需求，以用户的角度来使用软件，找出发生的scenerio，抽象成为一个一个Use Case，分析出Use Case之间的关系，这一步是非常重要的，这一步做好了，设计就成功了一半。Use Case的抽象有一些可以遵循的原则，这里不详细谈。

然后用语言描述每一个Use Case，描述用户使用一个Use Case发生的主事件流以及异常流。

这样就完成了需求分析阶段。

二。概要设计(找出实体 + 分析实体类之间的关系 + 提取控制类 + 画序列图)

接下来做概要设计，针对每个Use Case，读Use Case的描述，看事件流，找出所有的实体类，这也有一些可以遵循的原则，例如找出所有的名词，画表格排除等等方法。

然后分析实体类之间的关系，是包含，聚合还是依赖，是1：1，还是1：n，还是其他....，根据这些关系，就可以得出实体类和别的实体类想关联的属性，然后再找出每个实体类本身重要的属性。

然后再次分析Use Case的事件流，一方面check实体类的设计是否合理，另一方面你可以找出动词，分析对实体类的控制逻辑，这样就可以可以设计出业务控制类，一般你可以一个实体类一个控制类，也可以业务逻辑相关的实体类由一个Facade Session Bean(非EJB含义)来统一控制，这里面的控制类的颗粒度就由你自己来掌握了。一般来说先可以设计一些细颗粒度的控制类，然后再按照模块，用粗粒度封装细颗粒度的控制类，提供给Web层一个Facade。

然后你可以画序列图，就是用序列图来表达事件流，在这个过程中，你需要不断回到类图，给控制类添加方法，而序列图就是控制类的方法调用。

至此，你已经在Rose里面完成了概要设计，当然你不可能一次设计完善，会有很多次迭代，因此你不能一开始把类设计的太详细，只抓住主要的属性和方法，特别需要注意的是，是抽象的设计，不要用具体的编程语言来表达类。

三。实施(结合xdoclet和Schema工具自动生成代码)

然后你就可以抛开Rose了，转到Eclipse+Togehter里面，根据那些类，规划一下package层次，然后在Together里面进行类的详细设计，所有需要的属性一一写上，当然你还是不可能一下把所有的属性方法写全，不过没有关系，把重要的写好就行了。

然后类框架已经生成好了，给所有的实体类加上xdoclet，然后生成hbm，然后用Hibernate的ExportScheme生成DDL，运行一遍自动创建好所有的表。这样所有的实体相关类全部做好了。

你现在就集中精力把控制类那些方法里面的代码填写上就OK了，在这个过程，你会发现有些实体类缺属性，没有关系，加上属性，然后写好xdoclet，运行一遍，自动生成hbm，自动创建好表，然后继续写你的方法，也有可能你发现控制类缺方法，那么就加上。

基本上实体类就是getter/setter，和少量的实体相关方法，所有的控制逻辑都写在控制类里面。

最后你的软件就基本写好了，用Eclipse生成好一堆你的testCase运行测试，反复修改，除bug。

看看使用OOAD的设计思路，是多么的爽的事情阿！你只需要把精力放到Use Case的抽象，实体类的关系总结，控制类的归纳。而当你使用Eclipse＋Together之后，你所需要写的代码只不过是控制类的方法实现代码，其他的都已经生成好了。另外可能需要写少量工具类。

Alex 2006-09-20 09:02 发表评论

[zt]UML类图介绍

Alex — Tue, 29 Aug 2006 14:30:00 GMT

摘要: UML 类图介绍一、 UML 简介 UML （ Unified Modeling ... 阅读全文

Alex 2006-08-29 22:30 发表评论

[zt]RUP之用例间的关系

Alex — Tue, 29 Aug 2006 14:23:00 GMT

这一段时间，参加了部门组织的 RUP 教学项目，由一位“外援”架构师为我们指导教练。最近一直在忙于业务建模，今天刚刚将自己负责部分的系统用例识别了一遍。其间一直有一个问题，缠绕着包括我在内的很多同事，那就是用例之间的关系——包含、扩展、泛化——到底该如何使用。

翻阅了同事去年参加 RUP 培训时带来的材料，终于能基本分清三者之间的关系。

用例是从系统外部可见的行为，是系统为某一个或几个参与者（ Actor ）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含 (include) 、扩展 (extend) 和泛化 (generalization) 这几种关系。

在分开介绍它们之前，先说下它们的共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1 、包含 (include)

　　包含关系：使用包含（ Inclusion ）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（ Base ）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。　

例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

2 、扩展 (extend)

扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（ Extension ）用例加以封装，再让它从基用例中声明的扩展点（ Extension Point ）上进行扩展，从而使基用例行为更简练和目标更集中。

扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

对于一个扩展用例，可以在基用例上有几个扩展点。

例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

用例详述里面大致可以这样来写：

执行查询

基本流：

1．员工选择查询功能

员工期望查询业务数据时，选择查询链接，从而启动本用例的执行。

2．系统转入查询页面，并显示备选的查询选项

3．员工填写查询条件并提交

4．系统验证查询条件的合法性

验证条件的格式以及简单逻辑，如大小、前后、范围

5．系统将符合条件的信息返回

系统将查询结果以分页列表的形式显示在页面上

6．员工退出查询功能

员工点击退出链接，返回到上一级页面

扩展点：导出、打印扩展点定义在步骤 5

导出

该用例是在“导出、打印”扩展点上扩展了执行查询用例

基本流：

1 ．如果员工要求导出，选择导出按钮

。。。。。。

由上例可以看出 : 扩展用例的事件流往往可以也可抽象为基用例的备选流。但是在基用例本身已经是一个很复杂的情况下，选用扩展关系将备选流抽象成为单独的用例可以使基用例行为更简练和目标更集中（当然上面的例子中基用例可能简单了些）。

4 、泛化 (generalization)

泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：

用例详述里面大致可以这样来写：

审批

基本流：

7．领导选择要审批的记录

领导期望审批记录时，选择待审批记录链接，从而启动本用例的执行。

8．系统转入审批页面，并显示记录的详细信息

9．领导填写审批意见

领导根据记录的合理性来填写个人审批意见

10．提交审批结果

工资调整审批

该用例是审批用例的子用例

基本流：

1 ．领导选择要审批的记录

2．系统转入审批页面，并显示记录的详细信息

3．领导填写审批意见

4．提交审批结果

如果调整幅度较大，则要提交上级审批

上面分析了用例之间的三种关系。其中最容易让人迷惑的就是包含关系和扩展关系得区别。如果你现在对两者还有迷惑，请再仔细的对比一下上面两者的描述：）。

Alex 2006-08-29 22:23 发表评论

pd:怎么样使CODE不跟这改变?

Alex — Sat, 26 Aug 2006 15:04:00 GMT

反向工程生成的PDM,表中NAME和CODE都一样,现在要修改NAME.
在修改一个表的NAME属性时,CODE属性也会跟着一起改变,怎么样才能让CODE不跟着NAME变呢?

Tools->General Options->Dialog->Name to Code Mirroring (去掉)

Alex 2006-08-26 23:04 发表评论