对组件化开发的再思考

标签: 随笔文章 | 发表时间:2012-02-02 21:34 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
还是先说明基于组件化开发带来的优势,首先原有到系统级的粗粒度控制细化到了到组件级别的细粒度控制,一个复杂系统的构建就是组件最终进行集成后的一个结果。每个组件都自己独立的版本,组件可以独立编译,独立打包和部署。其次产品组件化后可以真正实现完整意义上的按组件进行产品配置和销售,用户可以选择购买哪些组件,组件之间可以灵活的进行组装。另外包括我们说的配置管理,开发,测试,打包,发布完全控制到组件层面,带来额外其它很多好处,如我们常说的如果一个组件进行小版本升级,如果提供给外部的接口没有任何变动,其它组件完全可以不用做任何测试等。

组件化开发思路在SOA之前已经有成熟的组件化开发方法,只是在SOA出现后,SOA咨询,需求分析,设计实现方法论进一步融入到组件化开发中。各种底层基础技术框架的发展和完善,为组件化开发提供了根据完整的支持,推动组件化开发的发展,特别是在B/S架构下的组件化开发。回到软件生命周期,我们再来阐述下组件化开发的核心思路和逻辑。

业务建模和业务组件阶段

流程驱动IT以及SOA思想的进一步融合,再次改变原有的组件开发重点关注技术组件层面的问题。业务建模阶段重点包括了业务架构和数据架构,其导入仍然是端到端流程分析为主线导入。业务架构分析重点就是形成业务组件,也可以叫业务模块。

在这里重点还是业务组件的形成,要知道业务组件来源于流程分析和流程分解,业务组件本身就是高度内聚的多个业务功能的一个集合,业务组件之间本身就是松耦合,业务组件通过交互和集成可以完成一个更大的端到端流程。业务组件的识别仍然回归传统的流程分析加面向结构下面的CRUD矩阵分析等方法来分析高内聚性。矩阵分析包括了业务功能和业务数据之间的CRUD关系,也包括了业务功能和业务功能之间本身的关联和依赖性分析。

对于粗粒度的数据建模我们把它划归到业务建模阶段,该阶段的数据建模偏概念模型,后续在设计阶段再转化到物理模型和数据实体组件。同时该阶段的数据建模需要梳理出业务和流程中核心的基础主数据和核心业务单据,分析业务单据关联映射关系,协助前面谈到的CRUD矩阵分析。

在这个阶段最终需要输出的涉及到组件层面的产出物包括软件系统的业务组件,每个业务组件包含的业务功能或叫业务用例。整个业务系统中的业务实体,业务实体关系图等。

软件需求阶段

在这个阶段不做详细的说明,但是我们仍然需要理顺整个关系,即首先形成业务组件,业务组件是大的业务模块。业务组件下面有业务用例,这里的业务用例通过进一步的需求分析和开发,将业务用例转换为系统用例,然后对每一个系统用例进行详细的描述。业务流程-》业务组件-》系统用例是一个从顶向下,逐层展开的一个分析过程。

在传统的用例建模中,我们没太关注用例之间的交互,而将其延后到设计和实现阶段去完成。现在来看该工作需要提前,即从全系统来看,首先完成对业务组件之间交互的描述,对交互点和交互场景进行详细说明。在细化进入到一个业务组件内部后,需要对系统用例之间的相互调用进行描述。

对于数据层面则在软件需求阶段进一步细化,从概念模型阶段过渡到逻辑模型阶段,进一步细化业务功能为系统操作,分析系统操作和数据对象之间的关系。

系统建模和技术组件阶段

这个阶段即传统的架构设计阶段,我们仍然是组件化开发的一个重点,这里的系统建模和架构设计重点都变化为功能性架构。但是前面业务建模阶段已经有前期的积累。如果是业务建模阶段是系统分析的话,那么系统建模阶段是系统设计。

系统建模阶段第一个重点是要实现从业务组件到技术组件的细化,在SOA中我们谈到业务组件,服务组件和技术组件。在这里我们只谈业务组件和技术组件,并弱化服务组件的概念。首先进入了架构分层后,一个业务组件可能需要拆分为多个技术组件,包括数据层组件,逻辑层组件,UI层组件,数据实体组件等。其次在该阶段我们会引入很多的纯技术层面的组件,这些技术层面组件和业务完全无关而和平台非功能性架构有关,如安全,异常,日志等相关组件等。

业务组件本身符合高内聚性,转换到技术组件后仍然需要符合高内聚性,技术组件之间其一不允许出现相互交叉调用,其二整个调用关系应该是从上层往下层调用。纵向看是UI组件->逻辑层组件->数据层组件调用关系,而横向看则是同层之间的各个技术组件之间存在相互调用关系。按照组件最大化复用原则,优先考虑UI组件复用,其次考虑逻辑层复用,最后才考虑数据层复用。

根据前面分析可以很明显的看到在系统建模阶段关于组件分析和设计的几个重点内容。其一是业务组件转换为技术组件,并按层分解。其二是根据业务交互,用例交互分析组件之间的调用关系,这些调用关系就是组件间的接口,通过业务和流程分析的方法来找到接口,转到相关组件的接口设计上,组件之间的调用只能通过接口,组件内部完全黑盒。其三是数据建模和设计,将前面数据建模分析内容转换为数据实体组件,数据实体组件只含数据实体,实现控制类和实体类的分离。这样数据实体类容易变化为下层可以被多个逻辑层技术组件引用的组件。

在这个阶段在传统的架构设计文档上,可以看到需要输出的内容包括了业务组件->技术组件的对应清单,组件调用关系和依赖关系图,组件接口设计文档和接口清单,可复用组件抽取和分析,组件包视图和部署视图,整个应用系统的组件化后的产品结构视图和配置项清单等。

实现阶段

实现阶段我们关注的问题即一个技术平台或框架支持组件化开发,测试和部署。传统的BS架构开发我们比较难以解决的问题是UI层内容的独立打包和部署,而现在类似T5框架可以做到更好的支持。T5框架再加上OSGI可以比较好的实现我们需要的组件式开发,动态发布部署,组件热插拔等基本需求。

可以单独对组件进行自动化的单元测试,当某个组件有变化的时候,可以单独对变化的组件进行版本升级,单独对变化组件进行部署。整个产品的版本由应用系统管理到里面的每个组件,这些都将是发生变化的点。

相关 [开发 思考] 推荐:

对组件化开发的再思考

- - 人月神话的BLOG
还是先说明基于组件化开发带来的优势,首先原有到系统级的粗粒度控制细化到了到组件级别的细粒度控制,一个复杂系统的构建就是组件最终进行集成后的一个结果. 每个组件都自己独立的版本,组件可以独立编译,独立打包和部署. 其次产品组件化后可以真正实现完整意义上的按组件进行产品配置和销售,用户可以选择购买哪些组件,组件之间可以灵活的进行组装.

关于软件开发的一些常识和思考

- - 博客园_知识库
  作者的观点:程序员在最初学习BASIC、Fortran、 Pascal、C、C++等语言时会感觉一个比一个好,不免有喜新厌旧之举. 而如今的Visual Basic、Delphi、Visual C++、Java等语言各有所长,真的难分优劣. 能很好地解决问题的编程语言就是好语言. 开发人员应该根据实际情况,选择业界推荐的并且是自己擅长的编程语言来开发软件,才能保证有较好的质量与效率.

API快速开发平台设计思考

- - DockOne.io
在我之前谈API网关的时候曾经谈到过快速开发平台,即将API快速开发的一些内容放入到API网关中,实际来看围绕API全生命周期管理,本身包括了开发态,运行态,运维态. 对于API网关更多的是解决运行态的问题,API网关本身应该轻量化设计,不做太多的协议转换,适配,数据映射等工作,这些工作应该放到API开发平台来完成.

终极思考

- wei - 牛博国际
我的海淀剧院演讲门票放出后,八小时卖了四百多张,同事们说,日. 我淡淡地说,别这样,也许正是因为便宜才这么好卖嘛. 一转身我马上就打电话给老婆,操. 早知道就他妈把票价定高一点啦,真倒霉......干. 很大程度上,这可以解释两件事:1.为什么已婚事业男性的健康状况会相对好一些. 2.为什么在社会上受到尊重和认可的事业男性在老婆的眼里都是傻逼.

动车追尾的思考

- David Ruan - 扬韬
1、两列运行的动车追尾,绝对属于重特大责任事故. 雷电导致前车失灵,已经是责任事故了. 前车失灵,信号没有外发,又是责任事故. 调度体系没有发觉列车失灵,也是责任事故. 后车没有察知前车失灵,还是责任事故. 最后,后车发现问题,紧急制动系统有没有用也值得怀疑,因为后车司机据说是人工制动并殉职于岗位的.

重新思考电子书

- Alex - 爱范儿 · Beats of Bits
Hart,“古登堡计划”发起人,2011 年 9 月 6 日去世,享年 64 岁. 从 1971 年 Hart 制作第一本电子书,启动“古登堡计划”开始到 2011 年,Kindle、Nook 流行,正好经过 40 年. 如今电子书阅读器、电子书变得越来越流行,在北京的地铁上,你会经常看见低头拿着 Kindle、Nook、iPad、汉王的人们.

《系统思考》读后感

- 章明 - 所有文章 - UCD大社区
经别人推荐(都忘了是谁推荐的了~),买了这本《系统思考》,看完前几章,发现这是一本非常好的书. 全书的精华也都在前面几章,后面都是一些具体的案例分析. 为什么必须从整体研究系统. 将系统分块通畅破坏了你所试图研究的系统. 如果你破坏了系统内的连接,你就破坏了系统本身. 更奇妙的是,很多系统表现出他们的任何组成部分都不具备的特征.

Memcache架构新思考

- - ITeye博客
2011年初Marc Kwiatkowski通过Memecache@Facebook介绍了Facebook的Memcache架构,现在重新审视这个架构,仍有很多方面在业界保持先进性. 作为weibo内部数据处理量最大,对数据延迟最敏感的部门,基于本厂2年多来对mc的使用心得,我在本文总结对MC架构的一些新思考.

Google Reade关闭的思考

- - 猫星石 ~CafeNeko
关于google reader所引起的口诛笔伐已经看的足够多了,所以这里我并不想再去谈Google的这个决定正确与否. 我想说的是关于”后GR时代”的一些思考. 关于GR的好我已经听的太多,曾几何时我也是重度的GR脑残粉. 但是早在GR宣布准备关闭时,我一边看着GR里面永远也不会清空的条目,我就在想,我真的还是GR的脑残粉吗.

表单设计的思考

- - 腾讯ISUX - 社交用户体验设计 - Better Experience Through Design
我们几乎每天都会接触形形色色的表单,登录账号、填写信息以获取服务、发布内容等. 然而填写表单的过程往往不是特别愉悦的,我们需要消耗时间输入信息,点击提交,可能还需要等待审核;尤其是碰到较为复杂、流程长的表单,如果用户体验较差,很容易让人产生挫败感,在中途选择放弃. 那么,如何提高用户填写表单的效率,防止他们出错或中途流失,提升愉悦度及转化率呢.