自定义博客皮肤VIP专享

*博客头图:

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

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

博客底图:

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

栏目图:

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

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+

咖啡小驻

coffeewoo的专栏 :Thinking in UML

  • 博客(59)
  • 收藏
  • 关注

原创 【有明信息】虚实之间 ---关于企业架构是与非的探讨

管理理论自然为“虚”,将管理理论渗透到日常生活工作中,正视问题,运用管理方法,执行它,才能“实”。

2014-09-23 11:51:42 6472 3

原创 [有明信息]有明信息办公室2.0

有明信息办公室2.0

2014-09-11 15:38:57 7097 3

原创 [有明信息]重视测算,精校成本源头 ——浅谈房地产开发目标成本测算

目前,业内基本是以目标成本作为成本管理的原点,其作为后续成本控制的基线,同时也将在责任成本管理、前期设计优化、招投标管理等环节发挥有效的指导作用。可以说目标不准确,过程管控再严格,也将枉然。

2014-08-25 15:38:09 7081

原创 那么多微服务识别方法究竟该怎么选?

微服务设计的方法越多越混乱,越无法把控。思考角度越多越复杂,结果就越无道理可讲。

2022-08-15 18:50:08 631 1

原创 走出企业数字化转型困难的破局者为什么是中台架构

中台架构的出现并非人为制造而是应运而生上一篇我使劲儿吐槽了一把,把企业数字化转型困难的锅按在了IT行业背上,说IT行业落后的软件生产方式已经不适应后工业化时代、依托互联网高度协作的产业互联和企业数字化要求。IT人被我调侃成了背锅侠,腾讯阿里也调侃成了山大王。但背锅并不能掩盖我辈“挨踢”人的勤奋与创造力,今天就来点儿正能量压压惊,并为IT人正名。勇敢背锅,奋勇前行,不惧挨踢,笑看明天,才是我辈IT人应用的风骨。上一篇我说走出企业数字化困境的药方是需要把生产模式从手工作坊式变成工业化生产的专业化分工和产

2022-02-16 14:00:43 2114 1

原创 企业数字化转型困难的这个锅必须得IT行业自己来背

软件落后的生产方式才是企业数字化转型困难的病根这是老坛聊企业数字化转型和产业互联网系列的第一篇。这十几年来,我的全部精力都花在企业数字化这个大命题上了。扎扎实实的苦逼迷茫了很多年,思考问题到底出在哪儿,该怎么解决。最后我终于找到了问题的结症,也找到了治病的良方,又花了四年时间去开发治病的药。现在是时候将它们公开了。第一篇我必须得从吐槽开始,一是不吐不快,二是不知病因便无法治病。都说中国...

2019-09-03 13:41:44 1319 6

原创 [有明信息]房地产开发,如何让营销后队变前队----契合项目开发全周期,实现营销全过程管控

如何让产品设计以客户为中心,充分尊重客户需求与体验,建造针对性更强的产品?如何动态掌控供应量,精准制定推盘策略?地产企业已经面临现实的问题和挑战。在当前形势下,地产企业唯有变革创新。其中,让营销真正由“后对”变“前队”,是重要的一步。具体来说,我们认为应该契合项目开发全周期,实现营销全过程管控,自始至终做好项目开发价值链各个环节的工作,让营销活动贯穿项目开发始终,做到“营销全周期管理”。那如何改变?

2014-08-14 18:21:42 6796 1

原创 [有明信息]横向集成、纵向贯通 ——地产财务管理新思路

“横向集成,纵向贯通”的理念在世茂集团及有明信息同事的共同努力下已初见成效。“一体化运营”的管理思路及财务业务一体化管理平台无疑是地产行业从“粗放式”管理向“精细化”管理战略转型的最佳途径,也是“深陷泥潭”的财务管理从核算型向管理转型的基础。在财务业务一体化管理平台当中,体现了集团、区域(城市公司)、项目公司的纵向一体化管理,也体现了营销、财务、工程、成本、合约的横向一体化集成。

2014-08-08 11:22:53 8752

原创 [有明信息]科目导向,精耕细作 ——浅谈房地产开发成本管理

题记:2014年7月3日,世茂集团宣布,作为中国地产行业首家采用SAP ERP一体化信息平台的企业,世茂集团ERP系统已成功上线并取得卓越成效:自2013年全面运行以来,世茂集团成功采用这一“横向集成、纵向贯通”的信息化平台,实现了业务财务一体化、以及覆盖项目开发全生命周期的协同管理,并打造了全面的战略经营管控模式。原文链接:http://mp.weixin.qq.com/s?__bi

2014-08-06 11:40:58 6610

原创 《大象--Thinking in UML 第二版》已于近日在当当首发,同时邀请各位加入新浪微博[大象-thinkinginUml群]:http://q.weibo.com/1483929

《大象--Thinking in UML 第二版》已于近日在当当首发,感兴趣的朋友可以去看看http://product.dangdang.com/product.aspx?product_id=22625408 。先附上再版自序吧。同时邀请各位加入新浪微博[大象-thinkinginUml群]:http://q.weibo.com/1483929 再版序《大象—Think

2012-03-19 16:17:37 14442 31

原创 BPM 是与非 -- 什么是BPM,如何辨别是否BPM产品,以及如何选择BPM产品

BPM方兴未艾,然而眼见市场上BPM产品一片混乱,你方唱罢我上场,各色产品、各种概念粉墨登场。虽然百花齐放,但真正有志于实施BPM的客户却被这乱花迷了眼,实在搞不清楚BPM该怎么去做,最终失去对BPM的信心和关注。这于BPM的发展并无益处。由是撰写此文,从BPM的基本概念出发,讲解了一些如何辨别和选择BPM产品的建议。希望能为BPM市场的进一步发展带来一点帮助。什么是BPMBPM(Busi

2012-01-11 14:39:43 10076

原创 关于采用业务用例视图来展示、归纳、整理业务用例的三点指导原则

今日,网友LeoXu给我发了封邮件,提到了业务建模如何组织业务用例的问题。这个问题还是第一次被问到,而且Leo同学显然走了一点小弯路。在回答他的同时,他的这个问题也非常好,把它分享出来。另一方面,Leo同学显然是喜欢思考的,他给我问题的同时也包含了他的许多思考,这点要赞之。为了表示对他热爱思考的鼓励和赞许,特地在最后又留了一个问题,请Leo同学来回答。同时也欢迎各位网友就该问题畅所欲言!Leo同学

2011-11-08 14:18:20 9887 2

原创 我的微博开通啦

微博开通了!求粉~~~哈哈,大家有问题的话来这里找我吧:http://t.sina.com.cn/2038745921

2011-03-21 23:24:00 7461 8

原创 OO系统设计师之路--设计模型系列(1)--软件架构和软件框架[从老博客搬家至此]

软件架构是一种思想,一个系统蓝图,对软件结构组成的规划和职责设定。而软件框架是一个实现,一个半成品,是针对一个特定问题的解决方案和辅助工具。

2010-10-18 16:00:00 11765 10

原创 OO系统设计师之路--分析模型系列(3)--分析模型的调整和优化[从老博客搬家至此]

草图代表了需求的实现,是一个细节的表露。接下来的优化的调整,就以此为基础。主要的输入:草图,系统架构,业务规则,补充用例规约,系统原型。主要的输出:调整后的分析模型,子系统,组件视图和部署视图(针对分布式应用而言)

2010-10-18 15:58:00 9058 2

原创 OO系统设计师之路--分析模型系列(2)--怎样做分析模型 [从老博客搬家至此]

分析模型是系统的高层抽象,是高于实现语言和实现方式的。因此在做分析模型过程中,要跳出固有的java思维,C++思维,同时也暂时不要考虑设计模式的应用,而专心的,用OO思维把四个分析类的职责和交互,以及它们之间的关系定义清楚。如果说用例分析大部分情况下是程式化的(笔者正希望它是程式化的),那么你会发现,分析模型大部分工作也是程式化的。

2010-10-18 15:54:00 9014 1

原创 OO系统设计师之路--分析模型系列(1)--什么是分析模型 [从老博客搬家至此]

分析模型是高层次的系统视图,在语义上,分析类不代表最终的实现。它是计算机系统元素的高层抽象。笔者认为分析模型正是OO设计的核心,而设计类只是OO的实现手段。分析模型是MVC模式的经典应用。对比分析类的名称,MVC模式,读者应该能够发现分析类在OO和商业目标中精妙的对应关系:人,事,物,规则--actor,boundary,engity,control。这就是为什么笔者说分析模型是OO设计的核心。

2010-10-18 15:43:00 11061 1

原创 面向对象方法中的数据库设计

最近收到不少网友关于在面向对象的分析设计中如何进行数据库设计的疑问。在大象-thinking in uml一书里,我详细讲述了面向对象从需求到设计的整个过程,但确实对数据库设计着墨甚少。因此写这篇文章对这个问题详细说明,在第二版里应当也会加上这一部分。 先贴出一位网友的疑问以及我的回复,作为这篇文章的引子:网友fdshxp问道:在软件开发时要进行数据库设计,现在通常的做

2010-02-05 15:21:00 23674 33

原创 业务用例向系统用例转换方法的一个讨论

最近收到一封网友来信,询问关于业务用例向系统用例转换的问题。觉得这个问题比较有意义,涉及到了业务用例向系统用例转换的策略以及评判方法,特发表上来,并感谢rainyhuang网友:  rainyhuang的来信: Dear CoffeeWood, 你好,看过你的文章使我对OOA有了更深的了解,但我在实际工作过程中遇到了一个问题让我百思不得其解,请不吝赐教,谢谢. 

2009-12-22 14:28:00 9245 5

原创 蜂巢 - Thinking in Agile - 我们需要怎样的软件过程(2)

     第一篇文章以蜂群作为引子,讲述了作为一个优秀的敏捷团队,蜜蜂们是如何工作的。得到了众多网友热情的回复,首先在此做谢! 方法是靠不住的,人性才是永恒的   到现在为止,所有的回复中还没有人反对蜂群是最优秀的敏捷团队这一观点。似乎我们可以简单的这样认为:所有人都认同蜂群是最优秀的敏捷团队,如果我们要组建一个敏捷的团队,我们就有必要从蜂群那里学习点什么。毕竟

2009-07-28 01:43:00 8942 17

原创 蜂巢 - Thinking in Agile - 我们需要怎样的软件过程(1)

 前言 Thinking in UML 系列文章是从2005年开始写的,至2008年终成《大象-Thinkin in UML》一书,江郎才尽矣,UML系列文章也该停下来了。一方面固然是因为《大象-Thinkin in UML》一书已经掏空了我关于UML和OO分析设计方面的积累,实在已经没有什么新鲜玩意儿值得一说了;另一方面,2005到2009已经发生了很多变化,我的关注点也有所转移,这次是敏捷

2009-07-19 22:50:00 9930 24

原创 开发即过程!立此纪念一个IT新名词的诞生

近日拙文“Jazz--开放协作与开发即过程的前奏”参与了 Rational技术征文大赛 见http://tech.it168.com/focus/200903/rationalgame/index.html, 很荣幸获得了头名, 见http://www.itpub.net/viewthread.php?tid=1176225&page=1&extra=page=1不过对我个人来说最

2009-06-18 10:47:00 8925 14

原创 邀请大象一书的读者和广大网友写关于分析设计、建模方面的自愿者文章

一直以来都是我写给大家看。与Arthur网友的互动让我觉得,其实网友自己的心得体会也是非常有价值的,可能更符合学习者的心路历程。在我的博客里已经发表了Arthur网友关于“业务场景和业务用例场景的区别”的文章,写得非常好,这更加引起了我的兴趣,相信广大网友中藏龙卧虎者大有人在,如能将这些资源都发掘出来,对大家的帮助就更大了。 由于我的博客专注于系统分析设计和建模,有一定的知名度,将文章集中

2009-06-01 16:22:00 7129 9

原创 业务场景和业务用例场景的区别(作者:Arthur网友)

  简单点说,在以业务目标为边界的业务模型中,业务场景图描绘的是贡献于这个业务目标的什么人及其做的什么事,这些人和事的交互过程和完成顺序就是完成整个业务目标的流程。而这些人往往是业务主角、而他们所做的事便是业务用例了。所以我认为,绘制业务用例图和业务场景图并没有谁先谁后的问题,这两个图是互相验证的。可以先绘制业务场景图,然后把其中的泳道和活动拿出来,得到的就是活生生的业务用例。但根据业务场景图得到

2009-06-01 16:08:00 26647 13

原创 OO系统分析员之路--用例分析系列(8)--如何编写一份完整的UML需求规格说明书[整理重发]

 终于到了快结束的时候了,这将是用例分析系列的最后一篇,结果是得到需求规格说明书,以结束需求分析的过程。经过前面七篇的工作,我们从最初的业务用例获取入手,获得了业务用例模型,这是我们的业务范围;经过分析得到了业务场景,这是我们的业务蓝图;经过规划,得出用例实现视图,这是我们的系统范围;经过再次分析,得到了用例实现以及领域模型,包括用例规约,业务规则和业务数据,这是我们的概念模型。仅从需求所需的必要

2009-05-14 15:53:00 9654 7

原创 最近评论回复汇总

 Re: 《大�?Thinking in UML》读者专用反馈、答疑、讨论贴cej19820202 | 5/16/2009 10:19:44 PM | 删除回复 | 选择大哥 我的光盘丢了 怎么�?d=0.21383061977772044re:cej198202025/19/2009 12:25:32 PM | 删除有网友在CSDN上传了随书光盘的下载,你去下一个吧R

2009-05-14 15:46:00 3104 6

原创 OO系统分析员之路--用例分析系列(7)--用例规约的编写--业务规则和实体描述[整理重发]

先说说业务规则。笔者习惯将业务规则分为三种。一种是全局规则,这种规则一般与所有用例都相关而不是与特定用例相关,例如actor要操作用例必须获得相应的授权,用例的操作与授权级别相关,或者用户在系统中的所有操作都要被记录下来等等。这类规则笔者习惯于,并且也建议将它们写到用例的补充规约里面去,因为它们一般与具体的业务功能性要求没有直接关系。有时候,这类规则也被写到软件架构文档中。关于用例补充规约

2009-04-14 17:29:00 16688 13

原创 回复网友 man1231,关于业务目标界定的问题

man1231  咖啡,你好:      有2个问题请问:     1. 根据业务目标来确定边界,从而产生主角和业务用例。        请问,“业务目标”如何产生 ? 根据用户的描述或者根据标书的要求来就可以了吗?        在多个“业务目标”之间,有无层次关系?         能否对“业务目标”的梳理,有个更明确的做法?        “业务目标”

2009-03-06 17:23:00 3431

原创 回复网友xiaobai1023的用例分析问题

网友xiaobai1023: 谭老师,你好:我有这样一个需求:通过调度框架如(quartz)定时去执行一些动作,动作的内容是去取一些“原始数据”可能是一些文件,也有可能是通过socket向第三方系统发送一条命令得到的数据,将得到的这些原始数据通过一些数据的映射、转换组装成我的上层系统中的值对象上传。可能是需求简单的缘故,本身实践UML的时间也不长,产生了如下疑问,希望您能帮助解答一下,谢谢

2009-03-04 14:44:00 2944 9

原创 OO系统分析员之路--用例分析系列(6)--用例实现、用例场景和领域模型[整理重发]

 上一篇说到我们经过初步的业务分析,得到了用户、业务用例以及业务场景模型。这三项工作成果形成了基本的需求框架,并圈定了业务范围。这时应当做一份基线。当然,第一份基线所包括的内容是非常粗的,要达到完整的需求说明还有更多工作要做。这一篇就来说说详细的需求过程和产出物,以及这些成果对需求的贡献。在开始之前,还是提醒读者下载实例,本文下面只会从实例中挑选很少一部分来说明,对照实例读者将能更好的理解。

2009-02-09 21:41:00 9080 12

原创 《大象》勘误专用帖

1.网友newsunet的指正: P70:图3.21展示了实体发现的结果。翻阅前面的图,发现应该是图3.17。图3.21是一个预存话费的例子。 2. 网友 mrwang指正:P92的“概念用例视图”第一段:概念用例和业务用例之间的关系,一般来说这些关系有扩展,包含和精化。P122“概念用例模型”第四段最后一行:抽象出的概念用例通过包含,泛化,扩展关系连接到基

2009-01-12 14:59:00 6547 73

原创 用例规约要细致到万无一失吗?

网友的来信: 谭先生,您好!      最近在拜读您的大作《大象》,收益良多,正是我在寻找的一份有正在将uml运用于实际场景过程的好教材。在阅读中,我反复回顾并结合了我在实践中的一些积累。有一个关于用例规约的小问题想请教下。      先介绍下问题的背景,我从事的产品以web界面为主,业务逻辑本身并不十分复杂,产品设计人员产出物为 用例规约和原型demo,开发即开始进行相应的表设计,开发,没有做到

2009-01-12 14:36:00 6627 9

原创 关于业务用例抽象问题对网友的回复

 谭老师,您好我现在有一个疑问,在银行的自助终端系统进行业务建模时,客户端(即自助终端)连接银行中间业务平台系统。终端用户可以利用自助终端进行如下操作,如终端用户业务用例图所示自助终端的业务用例图如下图所示:问题1) 我把所有终端用户的请求在自助终端用例图里都概括转化为一个“业务请求”,您觉得这么做合适吗?应该怎么做呢?下面是订购机票的业务场景图,如下图所示问题2) 在这里

2008-12-31 13:59:00 3828 7

原创 OO系统分析员之路--用例分析系列(5)--用户、业务用例和业务场景[整理重发]

 很久没有动笔了,这期间承蒙许多朋友的喜欢和鼓励,再不写点东西就对不住这些朋友了。写点什么呢?按照原先的设想,应该开始动手写如何从业务用例转化到概念用例和系统用例,不过老实说这一步需要的是经验居多,而很难找出一个普适的步骤来。先暂时放一放吧,以后一定会写到的。上一篇讲到用例分析的一般步骤和方法,也给出了一个实例,不过没有做更进一步的说明,所以这一篇,笔者决定先罗嗦罗嗦之前的内容,说说业务建模中各种

2008-12-23 01:04:00 9156 5

原创 关于非行业服务软件的业务建模问题

网友 laibagefei 的邮件: 谭云杰,您好:我是您的一个读者,《大象》一书和您的blog我都在看,现在有一个必须要请教你一下,因为我看了这么多UML建模的资料,只有您讲得比较全面,而且自成体系哈。1. 我在做业务建模的时候,在第三步“绘制业务场景图”时,说是要使用Business Actor中的actor和Business Use case中的case组成活动图,但是我看您的Busines

2008-12-18 16:18:00 3317 6

原创 OO系统分析员之路--用例分析系列(4)--业务建模一般步骤和方法[整理重发]

 本篇开始之前先扯点闲话,商业应用系统开发经历了三个阶段:第一个阶段以计算为中心,分析设计围绕程序的运行效率,算法优劣,存贮优化来进行。90年代的大学课程讲的都是这些。第二阶段以数据为中心,分析设计围绕数据流进行,以数据流程来模拟业务流程。这也就是所谓的面向过程的分析模式。第三阶段以人为中心,分析设计围绕人的业务需求,使用要求,感受要求进行。这也就是现在的面象对象分析模式。 使用OO方法建立商业模

2008-12-16 00:15:00 11959 16

原创 提示:互动网限量销售60本我亲笔签名的大象,先到先得

 由于网友的要求买签名版的大象,昨天我跑到互动网的库房里签了60本,今天互动网开始销售了,先到先得。

2008-12-10 10:29:00 2065 4

原创 OO系统分析员之路--用例分析系列(3)--业务建模之涉众[整理重发]

 从这一篇开始,笔者将借助一个虚拟的实例来阐述获取用例的方法,以及如何判断用例获取是否完备,粒度选择是否合适。事实上,在做这些工作时,我们正在进行需求分析的第一个阶段,即业务建模阶段。借助这个例子,笔者同样会阐述业务建模到底应该做什么,做到什么地步才能说明业务需求已经完整,可以称为一份完整的需求规格说明书了。一般来说,只有当以下工作都完成,才能说业务模型建立完成,它们是:发现和定义涉众画定业务边界

2008-12-08 21:12:00 8029 2

原创 OO系统分析员之路--用例分析系列(2)--用例的类型与粒度 [整理重发]

在正式讨论如何获取用例之前,笔者觉得有两个问题还是先解释清楚为好,这对正确获取用例有很大帮助。这两个问题也是初学者最为困惑,也是最难掌握的。一个是各种用例类型之间的区别和用法,另一个是用例的粒度。 先说说用例类型的问题。 用例类型,有的资料翻译为版型,英文原文是stereotype。在Rose中默认的类型有business usecase , business usecase realizatio

2008-12-05 10:29:00 10787 12

原创 欢迎大象读者加入QQ群75809242讨论,感谢网友“网痞”建立“大象UML民间读者群”!

欢迎大象读者加入QQ群75809242讨论,感谢网友“网痞”建立“大象UML民间读者群”!Google了一下,找到下面这些的购买此书的渠道,供参考。互动网:http://www.china-pub.com/129881卓越网:http://www.amazon.cn/mn/detailApp?prodid=bkbk867375&ref=GS&uid=168-1030604-7625860当当网:h

2008-12-03 11:47:00 1973 2

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除