基本层次 软件的逻辑结构可以划分为下面四个基本层次: 从下往上依次是: 1:基础设施层——这个层次是纯技术层次,解决的是系统的物理问题,比如database gateway、网络通信、对象容器……这个部分与业务需求关系不大,是系统的物理条件。 2:business对象——在这个层次上,业务要素出现了,业务领域中的概念在这里实现。比如一个航运公司的系统,这里就应该有航线、航班、座位、乘客、登机牌……这些对象应该拥有与实际业务领域相符的属性、方法。 3:business流程&m ...
看了一篇讨论:http://www.cnblogs.com/yimlin/archive/2006/11/30/578333.html有些感想:并不是所有的行为都必须属于某个对象,有的行为似乎放在任何一个对象中都不合适,那就单独放在那里好了,没必要非要造出一个对象来,更不能把它硬安在某个对象上。 按照oop的方法,软件的逻辑架构可以分成下面几个层次: 1:基础设施层——这个层次解决的是物理问题,比如database gateway、网络通信、对象容器……这个部分与业务需求关系不大,是系统的物理条件。有很多技术框架帮助我们尽快的把这个层搭起来,比如web server、 ...
  • 03:20
  • 浏览 (632)
  • 评论 (0)
先说一个小笑话。有一个生产队队长,他对专家说:“现在我们生产队的地越来越多,牛越来越忙不过来了。我想要这么一种牛,他吃的草和普通牛一样多,但是干的活是普通牛的十倍。”专家说:“这种牛是可以造出来的,现在有基因工程。”队长说:“好吧,你给这造几头这样的牛。”于是专家找到了生物实验室,让生物实验室的人搞一个基因工程,把牛造出来。于是工程浩大,投资无法保证,合作多半是不愉快的收场。 现实世界里很多人分析需求的过程就类似于这位专家,他们把注意力放在用户提出的功能点上,而对用户的实际需求没有兴趣。有不少软件公司和程序员,其实都在做类 ...
  • 12:08
  • 浏览 (671)
  • 评论 (0)
程序维护的时候经常遇到两个困难:1、不知道这段代码是实现什么功能的(code —— function);2、不知道这个功能是实现什么需求的(function —— business)。解决第一个问题是比较容易的,大家都是搞技术的,一头扎进代码里去,看上几十分钟,通常就能明白:原来这段代码是从数据库里面找到前三个月一直处于停机状态的号码,然后把这些号码放到一个叫做QUIT_USER的数据表里面去。第二个问题就难了,经常从代码中是看不出来的,于是项目开发的过程中就制造出来了大量的文档,来帮助开发者交流这个问题,也让将来维护这段代码的人知道这个知识。我们可以查找与这段代码相关的文档,文档上说:这段代 ...
  • 16:00
  • 浏览 (549)
  • 评论 (0)
NGOSS(Next Generation Operational Support Systems)是由TMF(Tele Management Forum)提出的,他用于电信领域,是构建下一代OSS/BSS系统的框架。TMF提供了技术中立构架(TNA)作为NGOSS解决方案的技术构架,这样就把NGOSS建立成了一种标准,这个标准与实现他的技术相互独立。TMF还提供了一组测试方法,用于验证解决方案是否符合NGOSS的标准。完整的NGOSS框架有多个组成部分,这些部分也可以独立的实施,用于解决某个领域的业务问题。下面对这几个部分做个基本的解释:eTOM(Enhanced Telecom Opera ...
  • 15:45
  • 浏览 (639)
  • 评论 (0)
IT系统是根据需求建设的,而需求是从哪里来的呢?为什么这个世界需要一个这样的系统,为什么系统需要做成这样,不多做一些事情,也不少做一些事情,恰好就要做这么多事情?这些问题难道不是问题吗,难道需求是理所应当的吗,需求是从哪里来的呢,用户为什么有需求,需求为什么是这样?下面我做了这么一件事,把一个家庭的活动整理了一下,有下面一些内容:一个家庭的活动有这几个内容:工作、娱乐、购物、文化教育、医疗保健、人际交往。这个东西是不是可以看作中国城市家庭的一个生活模型。还需要加上一个活动:财务管理。这个活动不应该是与前面几个活动并列的,他应该是一种横向的交叉活动,就像下面这样:假如我们现在要规划一个家庭的IT ...
  • 13:36
  • 浏览 (492)
  • 评论 (0)
灵活的软件,可以更好的适应用户的需求。什么样的软件才是灵活的?一旦用户提出灵活性方面的需求,设计者经常想到的一个对策是:增加配置。在不同的业务环节上增加功能配置,哪里需要灵活性,就把配置写到哪里。配置为软件系统提供了无数个可能——这就是灵活性。但是配置经常复杂无比,失去控制。很多配置项目已经失去了业务意义,完全成为一种数学意义上的排列组合。按照一些配置的路线,业务无法形成闭环流程,走进死胡同。这样的系统,维护配置和维护程序本身一样复杂。配置,就是不需要编译的代码。实际上,软件最大的灵活性,来自于完整的业务模型。一个完整的业务模型,不需要华丽的技术——设计模式、先进的平台、巧妙的构思——这些都不 ...
  • 13:57
  • 浏览 (511)
  • 评论 (0)
我的第一个工作是在一家软件公司写程序,主要的客户是一家省级电力公司。工作主要是以项目的形式,项目签下来了,忙几个月,从需求调研到设计,编码,测试,然后现场调试,现场维护。做完了以后通常有一个空闲时间,然后进入下一个项目。每个项目的需求都有一定的差异,但是都是在同一家电力公司里,尽管具体的客户不同,解决的问题也不同,但是都属于同一个大的商业范围。现在已经离开这家公司近一年了。有时候思考以前的经历,更能摆脱那种身在此山中的迷惑,也能够在技术方面有一些回忆和反思。虽然已经是马后炮,毕竟工作还在继续,总结以前的经验对以后也是一种财富。对于其他人来说,也许能够有一些借鉴作用。也希望一代一代的程序员能够积 ...
一个7×24的帐务系统,一个每天都要开门营业的营业厅,运行了好几年了,小改小闹几乎天天不断,大的升级隔半年到一年就要有一次。外界还有新的系统要接在上面,不断的开拓新的接口,功能不断扩充……系统最近一次大的升级,就在今年的3月。当时开发公司来了几十个人,平时人烟稀少的机房里面挤满了人。升级前一天的晚上,项目经理召集广大人民群众,发表升级前的最后一次讲话:“大家忙了n个月,就是为了这一天。再给我顶住,到明天这一切结束的时候,胜利将属于我们!”我站在边上,对我的同事说:“到明天,当新的系统开始运行的时候,一切只能说刚刚开始。 ...
  • 00:36
  • 浏览 (438)
  • 评论 (0)
很快又到了大学生毕业的季节了,很多同学将要走上工作岗位,回想一下自己工作这几年的经历,很想对他们说几句话,尤其是各位搞IT行业的.工作是一种责任,一个岗位必然意味着一种责任.一个人能得到什么收入,不是取决于他做的事情有多少技术含量,只取决于他做的事情需要承担多大的责任.无论是给老板打工,还是自己创业都是这样.要工作就要承担责任,需要在职责范围内去作出决定.工作需要协作.知道别人在做什么事情,让别人知道自己做什么,为别人做事情,找人为自己做事情,推掉自己无法完成的事情--这就叫协作.不明白的事情要及时去寻找帮助,求助你的上级,同事,拉人加班,请人吃饭...总之不择手段.任务可以靠IQ完成,也能靠 ...
lane_cn
搜索本博客
最近加入圈子
存档
最新评论
评论排行榜