查看原文
其他

[答疑]如何零基础学会看UML类图?

潘加宇 UMLChina 2024-03-10
软件方法(下)分析和设计第8章连载[20210816更新]分析 之 分析类图——知识篇
评张逸的“状态和事件本质相同”(上)-DDD话语批评之一


某知乎网友
如何零基础学会看UML类图?
UMLChina潘加宇
不了解零基础是怎么零基础法。
如果说指已经掌握某一门面向对象编程语言,只是没有接触过UML或类似图形表示法,那可以找一本有图和代码对照的书看看。
符合有图和代码对照着看的书,一种就是以你熟悉的编程语言写的GoF设计模式书,基本每门语言都有。
例如,你常用C#,就搜“C# 设计模式”或“C# Design Patterns”的书,常用Swift,把关键词里的C#换成Swift.....
然后挑一本书里面UML类图的量比较大的。
例如:
9月23-24日网络软件需求设计方法学全程实例剖析公开课

[幻灯更新]9月27日-9月28日剔除“伪创新”和“无领域”的领域驱动设计-网络公开课

[2020.01加一套题]UMLChina建模竞赛题大全-题目全文+分卷自测(11套110题)

全程字幕-25套UML+Enterprise Architect/StarUML建模示范视频

[新增:鸵鸟]软件开发团队的脓包:皇帝的新装、口号党、鸵鸟、废话迷

《软件方法》书中自测题-题目全文+分卷自测(1-8章)16套111题

怪论:东北公司用用例做需求,反映了东北互联网落后?

别把洋垃圾当宝贝-评InfoQ中国“敏捷……”文章(一)

中文书籍中对《人月神话》的引用(完结,共110本):软件工程通史1930-2019、实用Common Lisp编程……

CTO也糊涂的常用术语:功能模块、业务架构、用户需求……[20210217更新]

UMLChina服务介绍

以下为凑字数文字:
8.2.4.3不要把“上下文”当作偷懒的遮羞布
“领域驱动设计”乱象中,和本节内容相关的一个现象是:把“限界上下文”当作遮羞布,闭门造车炮制“通用语言”。
例如,针对下面这段描述:
同样规格的联想ThinkPad X1 Carbon2021笔记本电脑,在淘宝的A店铺卖9999元,B店铺卖9888元,某单位从B店铺买了20台,贴上单位的条码编号,分配给员工使用。
有的人“哇,我发现(没错,他们不喜欢研读,喜欢'发现')商品在不同的上下文有不同的含义!”,活生生地把领域建模搞成玄学。
其实,好好思考一下,或者看看前人的归纳,就知道这里面涉及到不同的概念,在模型中如实描述即可,如图8-37,不需要故弄玄虚。
图8-37 如实描述领域概念
在不同上下文中使用同一称呼,而且有不同含义,这种情况当然是存在的,但应该在调查和思考之后确认。要提防因为没有能力或者懒得去剖析背后的区别,就随便乱说——我的上下文中,鹿就是马的意思,马就是鹿的意思,我的上下文里的商品和你的上下文里的商品不同……
8.2.4.4 核心域透镜
在为了软件开发而建模时,建模人员可能会用自己熟悉的非核心域术语体系来代替不那么熟悉的核心域术语体系,还引以为豪。例如,面对一段集装箱领域装箱规则的描述,建模人员立即在大脑中把它转换成自己熟悉的概念:栈、链表、树……而且认为这是“透过现象看本质”,甚至宣称“我就是程序,程序就是我”! 
Fred Brooks在《人月神话》中引用了James Coggins的一段话:

继续滑动看下一个

[答疑]如何零基础学会看UML类图?

潘加宇 UMLChina
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存