BlogJava-Junky's IT Notebook-随笔分类-design

业务驱动服务、服务驱动技术

junky — Thu, 01 Jun 2006 16:20:00 GMT

    在IT行业有两个越来越普遍的发展方向，一个是架构方面的，一个是方法学方面的，面向服务的架构设计师可以从中有所收获。第一个就是MDA（模型驱动架构），由提出CORBA的OMG模型提出。MDA认为架构设计师首先要对待创建的系统有一个形式化的UML（也是由OMG提出）的模型。MDA首先给出一个平台无关的模型来表示系统的功能需求和Use Cases，根据系统搭建的平台，架构设计师可以由这个平台无关的模型得到平台相关的模型，这些平台相关模型足够详细，以至于可以用来直接生成需要的代码。
      SOA的另一个基础是敏捷方法（AM），其中非常有名的方法是极限编程（XP）。AM的目标是仅仅创建用户想要的,AM的核心思想就在于其敏捷性－处理需求变更的敏捷性.
      那么，如何开始SOA呢？经过了几次讨论，大家已经度过了盲人摸象的阶段，实质性的进展是从5.30号晚上的那次讨论开始的。从那次后，已经逐渐的看清了方向。
      最佳的方法时开始构建较小的SOA，侧重于提高当前缺乏效率的交互性。例如，假设使用一个系统上需要重新键入到另一个系统的打印报告，将两个计算机系统紧密联系在一起，这会消耗时间、浪费成本，导致出错，而且数据无法保持罪行。可以设计一个简单的基于Web服务SOA项目，直接链接信息，将含更新的SOAP消息发送到合作伙伴系统，而不是打印报告。

　　开始简单的SOA使我们可以在作出大的决定前之前先衡量，并在出现大的问题之前获得小改善的经验。
所以，再次看到SOA的的第一条准则：“业务驱动服务、服务驱动技术”的时候，深有感触。这才是问题的本源，原来的几次讨论和想法，其实都偏离了轨道。

junky 2006-06-02 00:20 发表评论

软件项目开发模型探讨——引子

junky — Thu, 01 Jun 2006 16:12:00 GMT

“是我们创造了工具，并且使用它们，而不是相反”

任何的软件项目都有它存在的目的，都是为了解决一些现实中的问题。可以把这个成为这个项目的目的，可以把需要解决的问题的需求称作这个项目的需求。

任何的软件项目的开发都必然离不开了解需求、根据需求进行设计、根据设计进行实现这些过程。不管是多大的项目，也不管是采用何种开发方式。

但是，设计的方式却有多种，没有谁会规定，只有采用UML图进行建模才叫设计。也没有谁规定，只有“设计”好了的项目才能开始代码实现。

对于软件项目开发而言，大型的项目和小型的项目所面临的项目开发的问题是不同的。

一个人几天就可以完成的项目和几个小组好几个月才能完成的项目相比，它们面临的实际中的开发问题，和开发结束后面临的维护问题都是不可同日而语的。

而且，技术的角度上看，适合大的项目的开发方式也未必一定适合小的项目。

好了，说了这么多，我只是想说：

综上所述，软件开发过程是一个非常复杂的问题，对于做技术的人来说（尤其是做计算机软件技术的人），解决问题的方式只有一种，分析问题、根据问题设计解决方案、然后实现解决方案来解决问题（解决方案未必一定是软件）。

分析问题的第一步，就是把现实中的东西转换成为概念模型，这样我们才有一个讨论和研究的平台。如果没有一个明确的统一的概念模型，那么，无论做什么研究都会显得毫无意义（古代的智者和诡辩论者经常这么干）。

既然我们面临的问题是软件项目开发，那么我们第一个要做的就是把它建模，并且对它进行一下研究。

我会在接下来几篇文章中对它进行详细的阐述，并且针对我在项目开发中的一些经验、总结和思考提出我对这个问题设计的解决方案。

目的只有一个，希望针对这个问题作出一些探讨。希望能够抛砖引玉。

junky 2006-06-02 00:12 发表评论

项目管理:数据管理主要内容简介(部门级)

junky — Thu, 01 Jun 2006 16:11:00 GMT

序号	物料主数据收集、整理、上载应该考虑的问题（参考）
1	收集现状各种物料分类方法
2	收集现状样板物料信息
3	分析物料编码方法
4	分析物料组编码方法
5	讨论物料编码、物料组、其它分类方法
6	设计数据收集初步模板
7	讨论物料编码、确定物料组编码
8	向用户提供数据收集模板
9	讨论数据收集、备份流程或方法
10	按所定流程或方法试收集数据、提供数据样板
11	手工创建样板数据进行初步测试
12	进一步修正数据模板
13	进一步确认数据收集流程或方法
14	按阶段全面收集数据
15	按阶段全面整理数据
16	收集过程中因其它变更需要对方法与模板变更的讨论
17	收集数据过程中出现的各种情况随时反应并讨论解决方法
18	全面备份数据
19	全面整理数据
20	数据的补充收集
21	数据初步确认定稿
22	数据上传程序开发清单的确定
23	数据上传程序的开发
24	数据上传程序的测试
25	上传测试样板数据
26	上传全部数据到测试系统
27	全面测试
28	数据的补充收集
29	数据最终确认定稿
30	数据上传程序最终确认
31	上传数据到生产系统

junky 2006-06-02 00:11 发表评论

专业专题点评：浅谈系统间数据传递与数据一致性的核心技术模式

junky — Wed, 31 May 2006 15:08:00 GMT

在写这个专题时，心情很怪异，如果您是专业人土，应该对下面的看似简单的模式有所触动，对于本人来讲，这简短的几句话意味着的是上百万的项目成本与近两个月的项目延期的问题，因此，本人显然对所有经历过的大型项目中IT人员在此专题上的表现非常不满意，因此把个人的想法在此与您分享，希望对您有所帮助（下面场景以A系统上传数据到B系统，此方案不考虑中间件模式，主要从业务需求的角度上来分析）：
1、考虑从A系统重复上传数据至B系统的问题。
       1）、通过上传数据时使用同一关键字可自然避免此问题。
       2）、如果业务流程中难以使用同一关键字，则首先要明确A、B系统中各自数据行的关键字，然后一定要在从A系统上传B系统时将A系统的关键字赋值到B系统数据行的某个字段，且这个字段一定要方便查询，如具有搜索帮助功能的字段。
       3）数据上传是否成功需要反回值，并在A系统中有所记录，单独做日志记录或修改上传数据行状态需根据需要而定。
       4）强调3），判断数据是否成功上传的方式严格意义上来说应该是在上传动作处理完后到B系统去抓对应的数据，除非B系统是非常标准可靠的大系统，接口为标准化可靠技术，才可以通过反回代码来判定是否成功上传数据。
       5）区分第1次上传与第1+N次上传处理，如，当第2次按下了上传键，则首先要去查看数据行状态，如果为上传成功状态，则取消后续操作，如果为不成功，则要谨慎对待，这时严格做法是去B系统搜索是否上传成功，如果B系统已成功，但A系统状态没改过来，出现报警日志，需手工确定、处理，如果B系统的确没有该数据行+A系统中状态为未成功，则可执行第2次上传任务。注意这个“+”，少了它，您的逻辑就缺乏严谨性了，例如，上传B成功，但在返回值时出现异常，从而出现重复上传。
2、考虑某些异常处理方法。
      1）、如上所述，如果自动上传失败，您要有手动处理的方式。
      2）、要具备既能自动批量上传，也可以手动批量上传的功能。例如在A、B系统成功对接前，需要在A、B系统中手工单独处理业务数据，一旦对接成功，这时需自动上传，那么在此之前的业务数据需要补充上传；或是在某种特殊情况下需要暂停A系统上传B系统，后续再补提，那么在程序开发时需要考虑到这种业务需求，建议是通过某种方便的“闸”来统一控制，如定制参数等。“闸”的优点是统一、同时、一个不漏的控制业务对象。
3、定期的、规范的数据校对功能。
      如果不是A、B双向接口，缺了这一功能，是您的失误。由于A上传B，通常会要求A、B两系统中的基础数据一致、业务数据同步一致，但往往很难从技术上去解决A、B系统双向接口，这时我们需要考虑到当B系统单独更改了基础数据或是从A系统上传的数据行时造成的数据不一致的校正工作。
      或许有人说我们在流程上已经规定了A、B系统单独修改时必须同时更改，但是作为IT人员应该穷举所有的特殊情况处理，比如，操作人员没有按流程去做呢？
      因此，建议按具体业务来定统一校对工作，注意，不同的业务校对的时间间隔可设为不同，且要具备错误后续处理功能。
其它相关原创文章：
        1.大型软件系统应该具备的一些细节功能
        2.专业专题点评：浅谈物料编码与技术实现
        3.专业专题点评：数据归档/删除处理逻辑简介
（特别说明：以上为个人观点，仅供参考，本人不对此方案负任何责任！—ERP Senior Consultant Vilion）

junky 2006-05-31 23:08 发表评论