系统架构_wczwcg的博客-优快云博客

自定义博客皮肤VIP专享

*博客头图：

点击选择上传的图片

格式为PNG、JPG，宽度*高度大于1920*100像素，不超过2MB，主视觉建议放在右侧，请参照线上博客头图

请上传大于1920*100像素的图片！

博客底图：

点击选择上传的图片

图片格式为PNG、JPG，不超过1MB，可上下左右平铺至整个背景

栏目图：

点击选择上传的图片

图片格式为PNG、JPG，图片宽度*高度为300*38像素，不超过0.5MB

主标题颜色：

RGB颜色，例如：#AFAFAF

Hover：

RGB颜色，例如：#AFAFAF

副标题颜色：

RGB颜色，例如：#AFAFAF

预览取消提交

自定义博客皮肤

上一步保存

wczwcg 优快云认证博客专家优快云认证企业博客

码龄23年

暂无认证

10: 原创

108万+: 周排名

112万+: 总排名

3万+: 访问

: 等级

1029: 积分

5: 粉丝

2: 获赞

3: 评论

0: 收藏

私信

关注

分类专栏

最新评论

功能驱动开发FDD的探讨
ozzzzzz: 我强调整体模型不是需求模型，是基于几点考虑。 1、一个项目是否允许你在开始的时候能从容的建立一个整体的模型？至少从我面前对于国内的软件开发行业的客户来看，他们是不会给你这个机会的。因此绝大多数情况下，是在你开始进行这个项目前，这个模型就应该已经存在了。那么这个模型显然不是来自于具体化了的“需求”，而是来自更加宽泛化的“领域”。实际上我更加愿意称他为领域模型或者领域分析模型。 2、由于1的观点，同时再考虑到大多数的开发团体，都是在一个比较固定的领域范围内部进行工作。他们的工作应该能，也应该进行一定程度的积累。而这个领域分析模型，就是一个很好的介质。 3、由于领域分析模型非常强调于领域中出现的概念，因此以此为基础可以更加好的而简单的建立其对于领域的认识。而如果过多的从更加关注流程的需求入手，则复杂性和可认识性会大幅度降低。同时也应该明白，由于领域分析模型是FDD团队组织结构的基础性依赖，保持一个相对稳定的模型是非常必要的。 而这里一个关键的容易产生错误认识的点就在于，将这领域模型系统化到具体的软件结构系统中去，也就是你说的所谓“系统模型图”。 而在我们具体的实践中，往往开发团队的所使用的系统构架architecture是另外一个相对稳定的体系，并且这个体系也如同那个领域分析模型一样有很多类似的特点。因此完全可以在他们两个的基础上进行总计和提炼，建立一个更加针对化的快速开发框架。而一旦将两种结构混淆，那么本已经复杂的业务和系统结构，将会变得更加复杂和难于认识。同时也应该明确，如果业务同具体的技术实现过于紧密的耦合在一起，将会在今后的开发过程中造成业务的改变必须调整技术结构的后果。 而如你看我上面关于FDD的阐述，你会发现FDD在实现和实施层面有大量的陷阱和必须使用的技巧。这些方式和方法，是仅仅凭看书和思维不能体会到的。而即使有这个方面的培训，如果没有真正熟悉这个方法操作的人做现场过程的指导，也是很难一下子体会到其中的奥妙的。 同时我们也应该明白，agile的方法体系，很多说法所代表的内容和传统的观念还是有些区别。特别是FDD，方法的精致和结构的规整，很容易让使用者在本身固有的重型思维方式的引导下，走入于agile背道而驰的泥坑。这本身也是其复杂性的一个表现。
功能驱动开发FDD的探讨
ozzzzzz: 我来说说我关于FDD的一些看法。 1.FDD是迭代开发，这一点必须加以强调。 2.整体模型更大程度上是分析模型，而不是需求模型。更多的涉及的是会出现什么东西，而不是会实现什么能力。这个模型是更多的是从业务分析角度出发，而不是从软件系统实现角度出发。这个整体模型不是构架，而只是部门内容是构架的一个部分。这一点非常重要，基本上FDD处理复杂问题的强大，就是从这里开始的。 3.按照《action》《result》《object》创建特征列表。习惯上我们将feature翻译为特征，这里更加体现了这个feature是《object》的一些能力，而不是软件的一些功能。软件的功能往往需要一些特征集体发生作用。实际上在操作的时候，如果整体模型按照正确的原则进行了构造，那么出现一个肥胖的feature的机会是很少的。基本上每一个feature的完成都会在2-3天以下，有很多可能就是几个小时，更少的只有几分钟。 4.主程序员所负责的往往是自己熟悉的和有兴趣的分析类，项目经理没有权利去去给他们分配工作，而不能去指定他们去负责什么类。实际上FDD存在3个主要的关键的管理方面的角色，项目经理、主设计师、开发经理。这3个角色可以由3个人负责，也可以由2个人负责，当然也可以由一个人负责。但是不管如何，这3个角色的任务和工作都是不同的，必须加以注意。而feature必须有具体的人负责，但是注意这必须是在类都有了主人的情况下。 5.上一条我已经表明类的所有者的来历，关键是大家必须理解，任何的agile都不会存在什么详细设计。其实这个阶段的所谓设计，更多的是要找出一个feature是会涉及到什么类，而各个的类主人会按照什么协议参加到这个feature的建造中来，什么时间这些人可以参加到这个feature中来，以及他们之间的协议如何可以得到检查实施。 6.这个阶段相对任务比较明确，但是切记不要把所谓的传统软件工程的方法影响到其中，所谓的复审和评审都是不应该进行的，而是应该使用tdd和pp这样更加有效率的做法。特别是由于存在主程序员，pp完全可以在上一个阶段的头脑风暴中进行。可以说设计和构造阶段其实更多的时候不是没有明确的区分界限的，或者说设计阶段更多的时候是没有一个明确的阶段的。这其实体现了agiler一般喜欢的持续设计风格。 至于作者最后问的问题，根本就不是问题，是他对于FDD的角色和迭代不理解造成的误解。至于里程碑，在FDD中是很容易确定的，每一次迭代都应该是一个里程碑，而每一次提交给客户更加应该是一个大的里程碑。所谓的计划，其实就是确定feature优先实现级别，而这个优先实现级别其实就是来着客户的功能优先列表。这里的两个列表都是动态的，是会经常性的做出调整的，并且很多复杂情况下分析模型也是会有调整的，可能会出现更多的分析类，也就是说主程序员的负责的类会根据情况进行调整。 FDD其实是一个比较复杂的体系，至少我认为比RUP并不简单。FDD中有许多策略和技术方面的问题，不是那么容易理解。可以说FDD是为职业程序员预备的专业开发方法。其实任何一直agile都是职业程序员的开发方法，一般情况下应该存在一个教练的角色，主设计师往往就是承担这个角色。
使用Eclipse进行J2ME开发
favoyang@yahoo.com: 如果你是j2me技术爱好者，欢迎来到j2medev.com交流经验，发表您的技术文章，参与论坛交流。

系统架构

关注

关注数：文章数：1 文章阅读量：942 文章收藏量：0

作者: wczwcg

这个作者很懒，什么都没留下…

展开

IBM 的利用 Eclipse 开发基于 OSGi 的 Bundle 应用

网址：http://www-128.ibm.com/developerworks/cn/opensource/os-ecl-osgibdev/index.html2006 年 7 月 17 日开放服务网关协议 (Open Services Gateway Initiative)，简称 OSGi,为网络服务定义了一个标准的、面向服务的计算环境，为用户提供了开放的、面向服务组件的、易于部署的编

转载 2006-08-08 21:58:00 · 942 阅读 · 0 评论

系统架构

作者: wczwcg

IBM 的利用 Eclipse 开发基于 OSGi 的 Bundle 应用