自定义博客皮肤VIP专享

*博客头图:

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

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

博客底图:

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

栏目图:

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

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(40)
  • 资源 (7)
  • 收藏
  • 关注

原创 Clone Elements为什么是灰的

问题:这一项为啥是灰的以下为单宝华贡献的回答 2020-5-24 21:29参考⽂档https://sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/clone_element_as_new_version.html注意: 需要先将图形的版本号设置为1.0 以外的其他版本号,克隆元素的按钮才是可以点的,不然不能点。原因笔者分析:*默认最新创建的图形,版本号为1.0。*想要把⼀个元素克隆为⼀个新的版本

2020-07-31 08:20:01 131

原创 上百本中文书籍中对《人月神话》的引用(4)

《人月神话》于1975年出版,1995年出二十周年版。自出版以来,该书被大量的书籍和文章引用,直到现在热潮不退。特整理中文书籍引用--其实绝大多数还是老外写的。特别说明的是:本文只是陈述这些书引用了《人月神话》的事实,不代表推荐或不推荐阅读。有同学问这个是不是结合爬虫、机器学习之类整出来的。答:too simple, sometimes naive,哪有这么简单?目前只能靠人肉和少许金钱。*软件再造:面向对象的软件再工程模式,Serge Demeyer 等 著,莫倩 等 译,机械工业出版社,..

2020-07-30 10:57:35 152

原创 系统内部的变化不是扩展

刘京城 2020-5-28 23:04潘老师,有个问题我拿捏不定,想请教一下:如图示,左边第9步有一个是否的判断,是的话系统要标记子作业单全部完成,否的话就什么也不做。但我看书上有说基本路径里验证的步骤不要写是否,要直接写期望的结果,这里的第9步不是一个验证,只是一种规则,所以我直接写了是否,不知是否合适?然后我又想到另一种写法,如右边那样拆成9、10两步,然后对9下面的扩展路径里有个扩展。本来想着它其实是一个规则,是不是放在业务规则里更好,但我记得那是针对不引起交互变化的选择,这里其实是引起系统交互变

2020-07-29 08:42:56 99

原创 购物时使用第三方支付的业务序列图

Alan 2020-5-29 19:26抽空做了下测试题,竞赛题目,做满分确实难这题的是答案2,但我觉得应该是3UMLChina潘加宇答案C,就考一个知识点Alan嗯,分享拼单 参与拼单错了支付那条线是方向不大合理支付 修改成 第三方支付系统 请求用户授权,更符合事实焦利利是辅执行者商户APP 调 支付宝,支付宝弹出密码框,让用户输入密码UMLChina潘加宇再看看书里,关于辅执行者部分,还有业务序列图的抽象级别部分有讲。这个画的是对的。.

2020-07-28 09:13:41 865

原创 Robert C. Martin《架构整洁之道》里面的or、er图

龙仔 2020-5-26 15:17我最近看了Bob大叔《架构整洁之道》里面的图,记得您上课说过什么or和er类属于假OO,貌似书里这样的图还不少,您怎么看UMLChina潘加宇我书里相关内容的截图是这样的Robert C. Martin这本书我也看过,毕竟他说的是“服务”不是类,这样命名也不是不可以。不过借题发挥一下:Robert C. Martin写的书里面(包括《敏捷软件开发...》等)很多地方,类也都是这种er、or类,没有属性,全是操作,然后SRP、OCP什么的喊.

2020-07-27 10:13:03 529

原创 “规则很复杂”的价格的建模(续)

Alan 2020-6-2 10:01在并多的案例中,计算价钱由拼单子订单完成,拼单子订单有数量,就能计算价格,实际上计算价格影响的因子比较多,比如价格,2件以上再打9.5折,顾客类型(高级会员),在总价高于200时还能再0.95折,还有不同的包邮类型决定最后价格,针对并多多的计算价格,采用面向对象来设计,合适的做法有A. 提供一个计算价格的类 feeCount ,把所有参数传给这个类去算,后续有变更规则,只需要修改此类的逻辑即可B. 仍在拼单子订单计算,把顾客对象,商品对象的类传入子订单C

2020-07-26 10:59:31 183

原创 处理超时无响应算不算需求

Alan 2020-6-7 11:03UMLChina潘加宇(1)通过不断追问“不这样可能会怎样”,找到当前涉众利益之下“系统不这样不行”的“最佳击球点”。为什么会有“外界无响应,系统要做某些事情(例如注销会话,释放资源)”的想法?原因可能是资源有限,如果不这样做,就无法以多少多少的资源支撑多少多少的并发使用,这可能才是真正的“不这样不行”。(2)和这个用例特定相关吗如果这样的问题其他用例也存在,不管“最佳击球点”是什么,都不能写在这个用例的规约里,最多是在用例规约最后,针对某个用例

2020-07-25 09:41:38 841

原创 作业单打印和发放的责任分配

刘京城 2020-7-4 18:19潘老师,有个批量操作的问题我想不太清楚,想请教一下。用户在打印作业单时通常都是一次批量打印的。分析阶段不考虑时间与空间因素,所以在类图上我画的打印事件与作业单是一对多关系(一次打印多个作业单)。在彩色建模画分析序列图的套路中,单个作业单收到领域事件“打印”,请求“部件”执行打印规则,然后作业单创建“打印”对象(保存),最后作业单自己改变状态。循环这一过程直到所有作业单打印完成。但这样一来,每个作业单都创建了一个打印对象,与我画的类图一对多关系矛盾了。假设类图是

2020-07-24 09:43:05 108

原创 “遗留系统“的UML建模有没有不同

qiuyong: 2019-1-11 12:45我来公司两个月了。公司有一套零售门店系统,领导让我负责在现有系统基础上开发,像这种"遗留系统",UML建模的知识还用得上吗,或者使用上有没有不同?潘加宇:"遗留系统"是一个从开发人员视角定义的术语,大致意思是(1)这个系统已经出现了比较长一段时间(2)这个系统的代码不是我写的(3)很可能接下来我要负责做一些事情来改进或集成这个系统。(3)是最关键的。符合(1)和(2)的系统非常多。各个岗位的工作人员已经出生了几十年,符合(1),代码是老爸老妈先

2020-07-23 07:03:27 91

原创 为什么面试的时候不考核心域的知识

织网的老男孩 2019-1-24 16:35:潘老师的《软件方法》强调主攻自己的核心域知识,而较为忽视非核心域知识—计算机基础等,工作中确实用不到,但是现在工作面试中就喜欢关注这些平时用不到的非核心域,每逢面试,很多都需要临时抱佛脚准备这些,用不上的东西又容易忘,各位怎么看,怎么应对的。。。。:我觉得潘老师的战略是对的,核心域的知识是核心竞争力,必须重视,但是也不是说非核心域的基础就不管了,非核心域的多体现在设计阶段,是这个阶段里面能力的体现织网的老男孩:明明是搞java业务开发的,大家

2020-07-22 07:35:54 219

原创 为什么要对术语“吹毛求疵“

鱼包日月 2019-2-7 18:21:潘老师,我发现您的好些竞赛题都在考察术语,也很认同您那篇关于术语的文章中对"用户需求"、"功能模块"等术语的剖析。我也想像您那样把严格使用术语重视起来,但又怕其他人说我太过挑剔,吹毛求疵,怎样把握分寸比较好。UMLChina潘加宇:很多时候我们低估了乱用术语背后的问题,甚至以为只是一种习惯,所以会怀着"百花齐放"的宽容心态。其实这是不对的。以张三春节回老家举个例子。张三在北京某知名公司工作,岗位是DBA。春节回到老家和亲戚欢聚一堂。大姨妈:三儿,我

2020-07-21 09:03:45 108

原创 发现在写代码过程中对需求的认识更清晰了?

大伟 2019-3-7 13:40:是不是对需求能力不强的人来说,跳过需求工作直接写代码更好?我发现在写代码过程中对需求的认识更清晰了。UMLChina潘加宇:这是逻辑上的错误归因。我先说一个笑话作为类比。*****************女儿:妈妈,二年级是不是比一年级懂得多呢?妈妈:是的。女儿:那我有个好主意,从今天起,我不做作业了,等到二年级的时候,我再来做一年级的作业。等到三年级的时候,我再来做二年级的作业。*****************之所以"对需求认识更清晰",是

2020-07-20 09:28:54 264

原创 Karl Wiegers的Software Requirements示例挑错

我针对Karl Wiegers的出了一道竞赛题,题目如下:[改错题]很多书中的建模示例都存在问题,包括一些“名著”。请根据《软件方法》知识,列举以下所给资料中和Request a Chemical用例相关的内容(包括用例图和用例规约)存在的问题。摘自Software Requirements, Third Edition(Karl Wiegers, Joy Beatty)回答格式如“执行者Requester的命名不合适”。解析(1)错误:用例图中,Buyer、T...

2020-07-19 07:05:34 215

原创 测试是不是不属于建模

半生不熟 2020-5-6 9:37请问老师,您书中列举的4个工作流没有包含测试,测试是不是不属于建模范围UMLChina潘加宇“测试”可以看作建模的验证过程,思考的还是那些内容,类似下面这张流行很广的图。当然,图上所用的术语统一为书中的术语就更好。所以不能光说“做测试”,也要清楚认识“测试”时的思考焦点。如果“测试”的是组织流程中各个系统之间的协作,那就是业务建模。如果“测试”的是目标系统的整体行为?那就是需求如果“测试”的是系统内部各个组成部分之间的协作,那就是分析(核心

2020-07-18 07:21:38 780

原创 上百本中文书籍中对《人月神话》的引用(3)

《人月神话》于1975年出版,1995年出二十周年版。自出版以来,该书被大量的书籍和文章引用,直到现在热潮不退。特整理中文书籍引用--其实绝大多数还是老外写的。特别说明的是:本文只是陈述这些书引用了《人月神话》的事实,不代表推荐或不推荐阅读。有同学问这个是不是结合爬虫、机器学习之类整出来的。答:too simple, sometimes naive,哪有这么简单?目前只能靠人肉和少许金钱。*程序设计的模式语言·卷4,Brian Foote 等 著,北京SPIN 译,清华大学出版社,2004..

2020-07-17 10:08:35 153

原创 创业公司玩不起建模?

WMWang 2019-3-9 9:50:潘老师,我现在在一家创业公司,看了您的软件方法觉得很有用,向老板建议老板说创业公司玩不起这一套,要尽快把产品做出来投放市场。我也感觉几乎没有创业公司做建模,都是直接堆代码,您怎么看。UMLChina潘加宇:绝大多数的创业公司活不到3年。如果别人怎么样,我也怎么样,那只能混吃等死。只有想得比对手深,比对手细,才会争得一线生机。许多创业公司的老板真的是过于自大了。就拿这句 "尽快把产品做出来投放市场"来说:怎样才能"尽快"呢?没有掌握分析设计

2020-07-16 09:30:37 162

原创 怎么评价领域驱动设计,它和UML是什么关系

最近经常被问到一些关于领域驱动设计问题,分几篇文章逐一回答。问题一:现在领域驱动设计很火,老师怎么评价,它和UML是什么关系?答:先给出看法:领域驱动设计是在软件开发分析和设计工作流上提出的一些做法。UML是表达分析和设计的可选表示法。进一步解释如下。先重复一遍《软件方法》第1章里的内容。A-业务建模——描述所研究组织内部各系统(人脑系统、电脑系统……)如何协作,使得组织可以为其他组织提供服务。B-需求——描述为了改进组织的问题,所研究系统必须具有的表现。C-分析——提炼

2020-07-15 10:05:24 755

原创 成人用品的UML建模

HarrisonY 2019-12-06 11:57潘老师,我读了您的书收到很多启发。我现在从事的工作比较偏门,做情趣用品,现在也越来越强调智能化创新,但我感觉很多是胡吹。要是想用书里的思想踏实做些事情,您认为对这个行业,哪些内容最重要?UMLChina潘加宇你的问题比较泛,能不能给我一些现在你最关注的项目的具体资料,如果涉及敏感信息,就给我类似的公开资料。HarrisonY马上,我发个文档(文档信息隐藏)UMLChina潘加宇资料我看了,这个行业还是挺有意思,我认真回答一下

2020-07-14 11:41:31 670

原创 动不动就担心“会不会过度设计“

刘文勇 2019-3-19 19:02:上课回去后,领导让我给同事分享。真像你课上说的,我还没怎么讲就有人表示担心"这样会不会过度设计""这样会不会不敏捷",真牛,你是不是见过很多这样的?UMLChina潘加宇:是的。思考是很痛苦的事情,有的人能逃避就逃避,并且为自己的懒惰找理由,只要能偷懒,哪管洪水滔天。将近二十年的经历告诉我,动不动表示担心"这样会不会过度设计""这样会不会不敏捷"的人,极有可能连基本的"设计"都不会,更不懂得什么叫"过度设计"、什么叫"敏捷",只不过把这些言辞作为自

2020-07-14 10:01:54 117

原创 警惕“没有最好,只有最合适”

小石头 2019-10-24 18:43上完课回到公司分享,确实有同事说“没有最好只有合适”,我记得您在课上针对这个说了一段话,但周日下午太困,没听明白,翻书也没有又找到。老师能不能告诉我在哪里。UMLChina潘加宇书上第一章有一部分:我再说得详细一些,下次出版时补在书里。****************************“没有最好只有合适”这句听起来理中客的话,其实很可能是无知和懒惰的遮羞布。我用数学类比一下。妈妈买了苹果和梨共320千克,其中苹果的重量比梨的4倍多20

2020-07-13 08:45:13 188

原创 上百本中文书籍中对《人月神话》的引用(2)

《人月神话》于1975年出版,1995年出二十周年版。自出版以来,该书被大量的书籍和文章引用,直到现在热潮不退。特整理中文书籍引用--其实绝大多数还是老外写的。特别说明的是:本文只是陈述这些书引用了《人月神话》的事实,不代表推荐或不推荐阅读。有同学问这个是不是结合爬虫、机器学习之类整出来的。答:too simple, sometimes naive,哪有这么简单?目前只能靠人肉和少许金钱。*UNIX编程艺术,Eric S. Raymond 著,姜宏 等 译,电子工业出版社,2011...

2020-07-12 14:43:36 212

原创 上百本中文书籍中对《人月神话》的引用(1)

《人月神话》于1975年出版,1995年出二十周年版。自出版以来,该书被大量的书籍和文章引用,直到现在热潮不退。特整理中文书籍引用--其实绝大多数还是老外写的。特别说明的是:本文只是陈述这些书引用了《人月神话》的事实,不代表推荐或不推荐阅读。有同学问这个是不是结合爬虫、机器学习之类整出来的。答:too simple, sometimes naive,哪有这么简单?目前只能靠人肉和少许金钱。*软件质量经济学,Capers Jones 等 著,廖彬山 等 译,机械工业出版社,2014..

2020-07-12 09:23:09 205

原创 针对张逸观点的一些评点

我看到张逸老师在最近的一些文章中喜欢提"老"字,例如:"我充分借鉴了事件风暴这种新方法,却又未完全抛弃UML这种老方法""若有可能,我还希望再加上一个ICONIX方法,虽然它已经垂垂老矣,但该方法蕴含的一些设计思想仍有值得借鉴之处"张逸老师的关注点从编码拓展到软件开发的全部工作流,值得称赞。不过每个工作流有各自的技能需要学习,是自己的感悟还罢了,如果要传授技艺给他人,更需要高标准严要求才对。所以,我就用建模思维剖析张逸老师近期发表的一些内容,供大家参考。就先从张逸老师上面这两句话开始吧。

2020-07-11 10:24:54 427

原创 解析美女出的一道状态机题(x、y和z值)

状态机如下图所示。如果对象创建之后,事件e2、e1、e3、e4、e1和e5按给定顺序发生,请问,事件发生结束后,变量x、y和z值分别是_______________________。【答案】x=-1,y=1,z=0。【解析】竞赛题的绝大多数题目是我自己出的,但本题来自Martina Seidl等所著的“UML @ Classroom”。Martina Seidl照片这道题目覆盖了状态机图的各个知识要点。先补充解释可能比较陌生的概念:(1)历史状态。历史状态(带圆圈

2020-07-10 14:01:36 616

原创 领导视察防疫、业务建模和阿布思考法

“阿布思考法”是《软件方法》提到的技能中比较容易误用的,估计仅次于“业务用例”,两者所需要的思考都需要突破平时的思考习惯。上图中这位同学以为这是阿布思考法,其实不是。先看《软件方法》P.132的截图注意,阿布思考法的用途是突破普通人的思维限制。随随便便“灵机一动”就能想到的,估计就不是阿布思考法了。阿布思考法是观察和思考顶级人物的昂贵方案,然后山寨出平价产品卖给普通人,而不是观察和思考普通人的方案,山寨了卖给更低级的人。就以这位同学说的“N95口罩”为例来说一说怎样才是正确的..

2020-07-10 09:35:15 378

原创 李白《月下独酌-花间一壶酒》的UML建模

中秋节前,我发布了一个广告,请大家用UML建模方法剖析李白的作品《月下独酌-花间一壶酒》,仅有两位同学交来作品,所以这两位同学都将获得清华大学出版社出版的图书一本。诗的内容如下:花间一壶酒,独酌无相亲。举杯邀明月,对影成三人。月既不解饮,影徒随我身。暂伴月将影,行乐须及春。我歌月徘徊,我舞影零乱。醒时同交欢,醉后各分散。永结无情游,相期邈云汉。下面,我用《软件方法》上册中的知识来剖析,如何从李白的这首诗开发出系统卖给李白这样的人。仅供参考。一、愿景老大:目标人

2020-07-09 14:28:06 259

原创 《实现领域驱动设计》的翻译错误

为了准备“领域驱动设计用语溯源”演讲(https://sz2019.archsummit.com/presentation/1791),把历年名字里带有"领域驱动设计"的书再过一遍。一般来说有英文资源我尽量看英文。之前在某群里看到有人夸"Implementing Domain-Driven Design"中译本翻译得好,根据我的经验,中译本经得起推敲的不多,于是就把该书英中对照看了一下。翻过前面的"译者序",原书第一句的翻译就存在不少问题。第一句原文:"With Implementing

2020-07-09 08:58:07 267

转载 电磁轨道炮设计-基于模型的系统工程(20190819更新)

作者 Dirk Zwemer原文链接:http://intercax.com/2018/07/19/mbse-for-railgun-design-part-1/本文的目的是展示如何组合一些工具来协作设计一款新的武器系统——电磁轨道炮(electromagnetic railgun)。使用的技术和工具有:SysML架构建模(MagicDraw或Rhapsody)、基于物理的分析(Mathematica和Simulink)、机械CAD (NX)和需求管理(Jama)。这些工具由两个Intercax工具.

2020-07-08 15:39:50 2393

原创 为什么“前Google工程师”会“感觉UML没啥用”?

前几天,有学员发给我截屏,一位“前Google工程师”在自己的网络课上发表了以下言论:这么多年来,发表类似“感觉UML没用”这样的言论的人,实在是太多了,包括“现Adobe工程师”、“现微软工程师”等等,大公司的名头确实唬住了不少人。我在《软件方法》中讲述到各个知识点时,也对此类言论有所评述。在此,我专门针对此类言论做一次集中回应。当惯了尾巴,理解不了脑袋所需的技能软件开发的一个迭代周期中需要思考四个问题,即四个工作流:A-业务建模——定位需要改进的目标组织(人群或机构)以及该.

2020-07-07 13:43:56 777

原创 UML硬核精细防疫指南的领域模型

几天前发了一篇《UML硬核精细防疫指南》(http://www.umlchina.com/article/2019ncovguide.html),带来了不少读者,刘京城同学提交的领域模型获得了本轮竞赛优胜。下面先给出刘京城同学提交的防疫指南领域模型(类图和状态机图)。刘同学画得很不错,把文章里提到的概念、关系和逻辑比较准确地理出来了,我在此基础上再来说说怎样精益求精,然后给出我自己画的防疫指南领域模型,并针对模型解释一些要点。时间有限,考虑未必周到,仅供读者批评指正。刘同学的类图和状态机图如图1-图

2020-07-07 08:46:52 599

原创 软件开发团队的脓包(1-3)皇帝的新装、口号党、废话迷

在严谨建模思维的扫视之下,软件开发团队中很多有意无意遮掩的脓包会被强制露出。接下来我会总结一些常见的脓包,供大家参考。脓包(1)皇帝的新装图片来自Wikipedia阿Q家徒四壁,连衣服都没得穿,觉得很丢脸。这时,有人和阿Q说,其实你这不叫没衣服穿,这是一种时髦,你穿的是“皇帝的新装”。像溺水的人抓住救命稻草一样,阿Q立刻被这个说法洗脑,以后都和别人说自己穿的是“皇帝的新装”,遮掩没有衣服穿的事实。在我刚开始为软件组织提供服务时,常听到软件组织的负责人和我介绍他们的团队“我们现在.

2020-07-06 15:26:30 368

原创 手机壳干架的软件工程指南

最近“产品经理和程序员因需求干架”的段子疯传IT圈。图1 传说中的干架剧本下面我用软件工程的观点来剖析这件事情。(1)需求不是为了指导设计而做的这里的产品经理,我定义为需求人员。程序员,我定义为设计人员。关于需求和设计,我在《软件方法》第1章中专门阐述(http://www.umlchina.com/book/softmeth_01.htm)。其中有一道自测题是这样的:★软件开发中需求工作的目的是____。 A) 让系统更加好卖 B) 更好地指导设计 C) 对系统做

2020-07-06 09:12:19 256

原创 《软件方法》第8章 分析 之 分析类图(4)

8.2.3识别类之间的关系-案例研究之前通过识别及审查类和属性,得到了如图8-112的类图。可以看到,经过前面的步骤,类图上已经有了所有要维护的关联关系,我们要做的仅仅是加上关联的细节。另外,没有泛化关系。图8-112识别及审查类和属性后得到的类图加上关联细节后的类图如图8-113所示。图8-113加上关联细节后的类图8.3工具操作【步骤1】展开“分析”包下的“实体类”包,双击“实体类”类图。单击工具箱中的,单击类图空白处,在弹出属性框中的“General”页签的左上...

2020-07-05 15:26:10 639

原创 《软件方法》第8章 分析 之 分析类图(3)

8.2.3识别关联关系8.2.3.1关联的三种形式UML规定了关联的三种形式:普通关联、聚合(Aggregation)和组合(Composition)。说到这里,我们有必要归纳类的关系如图8-90。图8-90类的关系有些书和文章里提到“泛化和组合”,其实是不合适的,因为泛化和组合不在一个抽象级别上。说“泛化和关联”可以。在图形表示上,普通关联是一根直线,聚合的整体一端是空心菱形,组合的整体一端是实心菱形。图8-91三种关联的图示当然,更重要的是意义不一样。之所...

2020-07-05 08:47:31 1628

原创 B站的UML+Enterprise Architect+StarUML建模视频汇总(1)

有30多个视频,可自由观看EA002制造执行系统MES系统用例规约-UMLChina建模示范视频 19:33https://www.bilibili.com/video/BV1pE411J72iEA006网约车系统迪迪出行分析状态机图-UMLChina建模示范视频 14:25https://www.bilibili.com/video/BV1rE411n743EA005微信餐馆业务用例图业务序列图-UMLChina建模示范视频 24:27https://www.bilibili.co

2020-07-04 15:14:27 896

原创 《软件方法》第8章 分析 之 分析类图(2)

8.1.6识别分析类和属性的要点8.1.6.1关于中英文命名该用中文就用中文,该用英文就用英文,该用日文就用日文。中英文命名问题和设计工作流(编码、设计数据库……)中碰到的问题是类似的。分析类虽然不包含设计工作流的知识,但它是设计工作流的基础。反对在设计工作流中使用中文命名(类名、属性名、表名、字段名……)的理由可能是编译器不支持、DBMS不支持、切换输入法太麻烦、版式不好看等。编译器、DBMS因素随着时代的发展慢慢地不再是问题,版式、切换输入法问题在画图建模中不存在,所以用中文名称不是大问题。..

2020-07-04 11:00:19 2326 1

原创 《软件方法》第8章 分析 之 分析类图(1)

墙上挂了根长藤,长藤上面挂铜铃《长藤挂铜铃》;词:元庸,曲:梅翁(姚敏),唱:逸敏,19598.1步骤3-1识别类和属性在业务建模和需求工作流,我们的思考焦点一直在待开发系统的边界外。现在,思考的焦点从外观过渡到内部机理。图8-1思考系统的内部机理系统如何构成,仅仅是软件开发组织考虑的事情,涉众不需要在意——只要系统能满足需求规约里阐明的各种需求。系统为了满足这些需求,必须封装一定的知识。如何组织这些知识,才能让建模人员的大脑更好地把握系统的复杂性,是分析和设计的关键。...

2020-07-03 15:27:46 6304

原创 《软件方法》第1章 建模和UML

牵着你走进傍晚的风里,看见万家灯火下面平凡的秘密。《情歌唱晚》;词:黄群,曲:黄群,唱:曹崴;19941.1 粗放经营的时代已经远去改革开放初期,中国出现了许多农民企业家,他们不用讲管理,也不用讲方法,只要胆子大一点,就能获得成功,因为当时的市场几乎空白,竞争非常少。农民企业家的思路很简单:人人都要吃饭,所以开饭馆能够赚钱。现在这样的思路已经行不通了。市场竞争已经足够激烈,十家新开张的饭馆恐怕只有一家能撑下来,所以农民企业家已经很少见(连农民都越来越少了)。软件业也一样,最开始的时候,会编程就了

2020-07-03 09:38:13 2785

原创 《软件方法》书中自测题大全-题目全文+分卷自测

已经根据最新版本内容更新了在线题库!以下是《软件方法》1-8章中的自测题,答案不直接给出,可访问每套题后面的自测链接或扫二维码自测,做到全对才能知道答案。知识点见《软件方法》(http://www.umlchina.com/book/softmeth.html)和“软件需求设计方法学全程实例剖析”幻灯片(http://www.umlchina.com/training/slide.html)《软件方法》第1章自测题11 [ 单选题 ] 软件开发中需求工作的目的是:A) 让系统更加好

2020-07-02 16:49:18 4075

原创 CTO也糊涂的常用术语:功能模块、业务架构、用户需求、文档……

功能模块、业务架构、需求分析、用户需求、系统分析、功能设计、详细设计、文档、业务、技术……很多被随口使用的名词,其实是含糊甚至错误的。到底含糊在哪里,错误在哪里,不仅仅是新手软件开发人员糊涂,许多入行多年的老手也一样。虽然很多老手功成名就,挂着CTO、总架构师等研发线的最高头衔,但是心里对这些概念也是一团浆糊。可能有的人会说,不会吧,这些牛人带团队做出了让公司赚钱的系统,怎么会不清楚呢,只不过表达出来和你的表达不同而已吧?我只能很诚恳地再说一遍:很多“牛人”真的不清楚。当然,搞不清楚不妨碍做出赚钱的

2020-07-02 11:51:41 2181 2

《软件方法2024版》公开内容202405更新-epub版

《软件方法》2024版 潘加宇 含 1、8、9 章部分内容 本文件会不定时更新,可到以下地址下载最新版本: http://www.umlchina.com/url/softmeth2024.html 当前更新时间:2024.5.22 ************************************************** 您在阅读《软件方法》时如果发现错误,欢迎通过微信umlchina2告知。如果作者认为有道理,决定在下一次发布时根据您的意见修改,每个错误将付给您5.12元报酬,并在书中说明您的贡献。 (1)任何您认为的错误都可以,包括错别字。 (2)同一错误仅支付最先指正者报酬。 (3)请根据最新版本作指正。 目前指正人有(按指正时间排序):吴佰钊、王周文、刘学斌、成文华、黄树成、李蜀斌、杨雪鸿、王书伟、高洪江、张志坚、龙燔、陈文飞、郭沼兵、陈自平、张彬、李宏伟、赵志军、孙赛刚、孙军、左科。 2018版《软件方法(上)》的勘误: http://umlchina.com/book/errata2ed.html

2024-05-22

幻灯片软件需求设计方法学全程实例剖析-04-系统用例图和用例规约

[幻灯片]软件需求设计方法学全程实例剖析-04-系统用例图和用例规约

2024-04-14

幻灯片软件需求设计方法学全程实例剖析-03-业务用例图和业务序列图

幻灯片软件需求设计方法学全程实例剖析-03-业务用例图和业务序列图

2024-03-29

幻灯片软件需求设计方法学全程实例剖析-02-愿景

幻灯片软件需求设计方法学全程实例剖析-02-愿景

2024-03-28

抱歉!二十三年前我们没看懂《人月神话》幻灯片-共127页

抱歉!二十三年前我们没看懂《人月神话》幻灯片-共127页

2024-03-15

DDD领域驱动设计批评-幻灯片合集(二)共183页

*领域驱动设计伪创新:通用语言 *被严重污染的领域专家 *不要把学习体会当成创新 *“以炮换马”的DDD歪招是否可以作为起步 *软件开发废话赏析02:领域驱动设计的“愿景” *领域驱动设计伪创新:六边形架构算吗 *分层架构是DDD提出的吗 *《实现领域驱动设计》译文暴露的问题 *为什么要追究糊涂用语 *DDD伪创新为什么受欢迎 *DDD伪创新的来源 *遮羞布:赶紧“敏捷”编码 *开发团队脓包01:皇帝的新装 *开发团队脓包02:口号党的危害 *开发团队脓包03:鸵鸟 *“敏捷”为啥无敌:起名的秘密 *普天之下皆我妈 01:如果允许一次走两步,新手也能击败象棋大师 *普天之下皆我妈02 :“敏捷”试错 *乱七八糟图最大的问题

2024-03-08

DDD领域驱动设计批评-幻灯片合集(一)共190页

DDD领域驱动设计浮夸,Eric Evans开了个坏头 领域驱动设计伪创新 之 聚合根 哪些中文资料上有领域模型案例 领域驱动设计割裂历史,哪里有详细一些的真实历史 软件开发废话赏析:事件风暴 领域驱动设计伪创新:为什么互联网是重灾区 用领域驱动设计解决鼠鸭问题

2024-03-07

pdf这210本书引用了《人月神话》-ppt版-共213页

《人月神话》于1975年出版,1995年出二十周年版。自出版以来,该书被大量的书籍和文章引用,直到现在热潮不退。 2023年,清华大学出版社推出《人月神话》纪念典藏版,大幅度修正了译文。 现摘录各种软件开发领域的中文书籍中对《人月神话》的引用,分享给大家。 共210本。

2024-03-06

潘加宇《软件方法》强化自测题业务建模需求分析共230题

在完成书中自测题的基础上,进一步强化

2024-03-03

潘加宇《软件方法》2024版本公开部分,196页

潘加宇《软件方法》2024版本公开部分,196页

2024-03-01

潘加宇 软件方法(上)业务建模和需求 第二版 自测题答案和解析,pdf文件,和书配套使用

潘加宇 软件方法(上)业务建模和需求 第二版 自测题答案和解析,pdf文件,和书配套使用

2024-02-29

UML+Enterprise Architect建模示范视频(字幕)合集-机场无人物流、科技创新平台、司法调解、房产评估、博物馆安全、跨组织结算、远程求医、期货

UML+Enterprise Architect建模示范视频(字幕)合集-机场无人物流、科技创新平台、司法调解、房产评估、博物馆安全、跨组织结算、远程求医、期货仓单、市场部营销活动、停车管理、财务软件、设备维护知识图谱、合同管理(催款)、三方采购、制造执行系统MES、房产中介考勤、会议室管理、微信餐馆、迪迪出行、并多多、迪迪出行、微信餐馆、会议室管理系统、考勤系统、制造执行系统、三方采购平台

2020-10-08

UML+Enterprise Architect建模示范视频EA001三方采购平台(字幕).mp4

UML+Enterprise Architect建模示范视频EA001三方采购平台,全程字幕,仅片段。UMLChina制作,建模带来竞争优势,利润=需求-设计

2020-09-23

UMLChina训练资料之需求

UMLChina训练资料之需求定义,2009年8月版本

2009-09-29

UMLChina训练资料

UMLChina训练资料,2009年9月版本

2009-09-29

UMLChina培训幻灯之四需求定义

UMLChina培训幻灯之四需求定义 使用用例来定义需求的精要,讲授者:UMLChina 潘加宇

2009-02-05

空空如也

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

TA关注的人

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