自定义博客皮肤VIP专享

*博客头图:

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

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

博客底图:

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

栏目图:

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

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(46)
  • 收藏
  • 关注

翻译 好友关系设计

1.背景1.1.关系链业务社交系统(微信、QQ,支付宝)需要解决的一个工程问题是如何完成海量用户关系存储,并高效查询。典型代表系统是微信好友、QQ好友、蚂蚁森林游戏中的好友关系、微博粉丝、知乎粉丝偶像列表等等。这类业务其实就是关系链业务,而关系链分弱好友关系和强好友关系。弱好友关系不需要彼此的同意,比如用户A关注用户B这类关注和粉丝的关系。而强好友关系需要经过彼此同意,比如用户A请求添加B为好友,用户B同意后,则AB就互为好友。1.2.举例举个例子:假设需要你设计蚂蚁森林这个系统,系统假

2021-09-17 18:45:50 899

原创 社区产品设计

一、「社区」产品的概念社区产品一直是很受欢迎的产品形态。其原因是:社区满足了我们生活中大部分马斯洛高阶需求,比如被尊重和自我实现等。很多人在知乎解惑,在天涯感叹人生,在虎扑认识了一堆家人。一个社区,就是一个身份,也是一段人生。社区让我们从一些共同点开始,不断发现新朋友,彼此熟悉,在共同的兴趣和方向上共同进步。所以为了分析清楚社区,我们必须先认知社区。不妨从社区和社区相关概念聊起,厘清社区、社交、内容、社群等强关联概念之间的关系。社区和社交有什么异同?社区更强调场,社交更强调关系。举例看下

2021-09-11 21:44:40 7591

原创 计算机网络-物理层、MAC层

OSI 七层模型通过七个层次化的结构模型使不同的系统不同的网络之间实现可靠的通讯,因此其最主要的功能就是帮助不同类型的主机实现数据传输 。完成中继功能的节点通常称为中继系统。在OSI七层模型中,处于不同层的中继系统具有不同的名称。物理层记得初中上网吧的时候,总有人喊局域网打CS啦。当时还不太知道什么是局域网,就只知道,可以不用上网,就可以组队玩游戏。物理层能折腾啥?现在的同学可能想不到,我们当时去学校配电脑的地方买网线,卖网线的师傅都会问,你的网线是要电脑连电脑啊,还是电脑连网口啊?.

2021-09-06 22:37:59 2122

原创 计算机网络-DHCP

平时自己玩虚拟机的时候,虚拟机都会自动有一个跟本地环境同一网段的ip。那你你了解背后的分配逻辑吗,其实就是用到了DHCP。动态主机配置协议(DHCP)动态主机配置协议(Dynamic Host Configuration Protocol),简称DHCP。有了这个协议,网络管理员就轻松多了。他只需要配置一段共享的IP地址。每一台新接入的机器都通过DHCP协议,来这个共享的IP地址里申请,然后自动配置好就可以了。等人走了,或者用完了,还回去,这样其他的机器也能用。所以说,如果是数据中心里面的服

2021-09-05 22:24:39 1856 10

原创 计算机网络-网络分层的真实含义是什么?

网络为什么要分层?这里我们先探讨第一个问题,网络为什么要分层?因为,是个复杂的程序都要分层。(个人理解是因为不同的网络设备处理不同的数据包,所以需要进行分层)理解计算机网络中的概念,一个很好的角度是,想象网络包就是一段Buffer,或者一块内存,是有格式的。同时,想象自己是一个处理网络包的程序,而且这个程序可以跑在电脑上,可以跑在服务器上,可以跑在交换机上,也可以跑在路由器上。你想象自己有很多的网口,从某个口拿进一个网络包来,用自己的程序处理一下,再从另一个网口发送出去。当然网络包的格式很复杂,

2021-09-04 21:54:11 721

原创 计算机网络-为什么要学习网络协议

接下来的将系统学习下计算机网络。分布式系统,无时不刻不都在进行着网络通信,可见掌握网络对于一个开发工程师是多么的重要。我们常用的网络协议有哪些?你先在浏览器里面输入https://www.kaola.com,这是一个URL。浏览器只知道名字是“www.kaola.com”,但是不知道具体的地点,所以不知道应该如何访问。于是,它打开地址簿去查找。可以使用一般的地址簿协议DNS去查找,还可以使用另一种更加精准的地址簿查找协议HTTPDNS。无论用哪一种方法查找,最终都会得到这个地址:106.11..

2021-09-03 23:24:37 351

原创 分布式系统性能-数据库扩展

读写分离 CQRS读写分离是数据库扩展最简单实用的玩法了,这种方法针对读多写少的业务场景还是很管用的,而且还可以有效地把业务做相应的隔离。如下图所示,数据库只有一个写库,有两个读库,所有的服务都写一个数据库。对于读操作来说,服务 A 和服务 B 走从库 A,服务 D 和服务 E 走从库 B,服务 C 在从库 A 和从库 B 间做轮询。这样的方法好处是:比较容易实现。数据库的 master-slave 的配置和服务框架里的读写分离都比较成熟,应用起来也很快。 可以很好地把各个业务隔离开来

2021-09-01 22:14:49 274

原创 分布式系统性能-异步处理

异步处理在分布式架构中,我们的系统被拆成了很多的子系统。如果想把这堆系统合理地用好,并更快地处理大量的任务,我们就需要统一地规划和统筹整体,这样可以达到整体的最优。本质上,这和邮递公司处理邮件一样,是相同的道理。在计算机的世界里,到处都是异步处理。比如:当程序读写文件时,我们的操作系统并不会真正同步地去操作硬盘,而是把硬盘读写请求先在内存中 hold 上一小会儿(几十毫秒),然后,对这些读写请求做 merge 和 sort。这就是异步系统所带来的好处——让我们的系统可以统一调度。异步处理的设

2021-08-31 20:58:51 578

原创 分布式系统性能-缓存

基本上来说,在分布式系统中最耗性能的地方就是最后端的数据库了。一般来说,只要小心维护好,数据库四种操作(select、update、insert 和 delete)中的三个写操作 insert、update 和 delete 不太会出现性能问题(insert 一般不会有性能问题,update 和 delete 一般会有主键,所以也不会太慢)。除非索引建得太多,而数据库里的数据又太多,这三个操作才会变慢。绝大多数情况下,select 是出现性能问题最大的地方。一方面,select 会有很多像 join、g

2021-08-30 22:19:11 299

原创 分布式系统治理-服务网格与网关模式

服务网格是 CNCF(Cloud Native Computing Foundation,云原生计算基金会)目前主力推动的新一代的微服务架构——Service Mesh 服务网格。Service Mesh 这个服务网络专注于处理服务和服务间的通讯。其主要负责构造一个稳定可靠的服务通讯的基础设施,并让整个架构更为的先进和 Cloud Native。在工程中,Service Mesh 基本来说是一组轻量级的服务代理和应用逻辑的服务在一起,并且对于应用服务是透明的。说白了,就是下面几个特点。Ser

2021-08-29 21:56:22 955

原创 分布式系统治理-边车模式 sidecar

所谓的边车模式,对应于我们生活中熟知的边三轮摩托车。也就是说,我们可以通过给一个摩托车加上一个边车的方式来扩展现有的服务和功能。这样可以很容易地做到 " 控制 " 和 " 逻辑 " 的分离。也就是说,我们不需要在服务中实现控制面上的东西,如监视、日志记录、限流、熔断、服务注册、协议适配转换等这些属于控制面上的东西,而只需要专注地做好和业务逻辑相关的代码,然后,由 " 边车 " 来实现这些与业务逻辑没有关系的控制功能。边车模式设计具体来说,你可以理解为,边车就有点像一个服务的 Agent,这个服务

2021-08-27 21:49:23 2937

原创 分布式系统容错-降级

所谓的降级设计(Degradation),本质是为了解决资源不足和访问量过大的问题。当资源和访问量出现矛盾的时候,在有限的资源内为了能够扛住大量的请求,我们就需要对我们的系统进行降级操作。也就是,暂时牺牲掉一些东西,保障整个系统的平稳运行。一般来说,我们的降级需要牺牲掉的东西有:降低一致性。从强一致性变成最终一致性。 停止次要功能。停止访问不重要的功能,从而释放出更多的资源。 简化功能。把一些功能简化掉,比如,简化业务流程,或是不再返回全量数据,只返回部分数据。降低一致性我们要清楚地认识到

2021-08-26 22:41:07 534

原创 分布式系统容错-限流

保护系统不会在过载的情况下导致问题,那么,我们就需要限流。限流的策略限流的目的是通过对并发访问进行限速,相关的策略一般是,一旦达到限制的速率,那么就会触发相应的限流行为。一般来说,触发的限流行为如下。 拒绝服务。把多出来的请求拒绝掉。一般来说,好的限流系统在受到流量暴增时,会统计当前哪个客户端来的请求最多,直接拒掉这个客户端,这种行为可以把一些不正常的或者是带有恶意的高并发访问抵挡掉。 服务降级。关闭或是把后端服务做降级处理。这样可以让服务有足够的资源来处理更多的请求。降级有很多方式

2021-08-25 21:43:11 343

原创 分布式系统之-分布式事务

什么是分布式事务随着互联网的快速发展,软件系统由原来的单体应用转变为分布式应用。​ 分布式系统会把一个应用系统拆分为可独立部署的多个服务,因此需要服务与服务之间远程协作才能完成事务操作,这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务分布式事务解决方案两阶段提交(2PC)熟悉mysql的同学对两阶段提交应该颇为熟悉,mysql的事务就是通过日志系统来完成两阶段提交的。两阶段协议可以用于单机集中式系统,由事务管理器协调多个资源管理器;也可以用于分布式系统,由一.

2021-08-24 15:18:47 169

原创 分布式系统容错-熔断

熔断机制借鉴于我们电闸上的 " 保险丝 ",当电压有问题时(比如短路),自动跳闸,此时电路就会断开,我们的电器就会受到保护。不然,会导致电器被烧坏,如果人没在家或是人在熟睡中,还会导致火灾。所以,在电路世界通常都会有这样的自我保护装置。同样,在我们的分布式系统设计中,也应该有这样的方式。前面说过重试机制,如果错误太多,或是在短时间内得不到修复,那么我们重试也没有意义了,此时应该开启我们的熔断操作,尤其是后端太忙的时候,使用熔断设计可以保护后端不会过载。熔断设计熔断器模式可以防止应用程序不断地尝试

2021-08-23 21:08:10 470

原创 分布式系统容错-重试

关于重试,这个模式应该是一个很普遍的设计模式了。当我们把单体应用服务化,尤其是微服务化掉,本来在一个进程内的函数调用就成了远程调用,这样就会涉及到网络上的问题。重试的场景所以,我们需要一个重试的机制。但是,我们需要明白的是," 重试 " 的语义是我们认为这个故障是暂时的,而不是永久的,所以,我们会去重试。所以,设计重试这个事时,我们需要定义出什么情况下需要重试,例如,调用超时、被调用端返回了某种可以重试的错误(如繁忙中、流控中、维护中、资源不足等)。而对于一些别的错误,则最好不要重试,比如:

2021-08-21 22:43:46 416

原创 分布式系统容错-补偿

分布式系统有一个比较明显的问题就是,一个业务流程需要组合一组服务。这样的事情在微服务下就更为明显了,因为这需要业务上的一致性的保证。也就是说,如果一个步骤失败了,那么要么回滚到以前的服务调用,要么不断重试保证所有的步骤都成功。所以对于分布式系统,我们就不得不说下补偿。ACID 和 BASE谈到这里,有必要先说一下 ACID 和 BASE 的差别。传统关系型数据库系统的事务都有 ACID 属性,即原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation,又称独立性)、

2021-08-20 21:48:54 651

原创 分布式系统容错-幂等性设计

所谓幂等性设计,就是说,一次和多次请求某一个资源应该具有同样的副作用。为什么我们需要这样的操作?说白了,就是在我们把系统解耦隔离后,服务间的调用可能会有三个状态,一个是成功(Success),一个是失败(Failed),一个是超时(Timeout)。前两者都是明确的状态,而超时则是完全不知道是什么状态。比如,超时原因是网络传输丢包的问题,可能是请求时就没有请求到,也有可能是请求到了,返回结果时没有返回到等情况。于是我们完不知道下游系统是否收到了请求,而收到了请求是否处理了,成功 / 失败的状态在返回

2021-08-19 22:17:57 172

原创 分布式系统容错-异步通信设计

前面所说的隔离设计通常都需要对系统做解耦设计,而把一个单体系统解耦,不单单是把业务功能拆分出来,正如上面所说,拆分完后还会面对很多的问题。其中一个重要的问题就是这些系统间的通讯。通讯一般来说分同步和异步两种。同步通讯就像打电话,需要实时响应,而异步通讯就像发邮件,不需要马上回复。各有千秋,我们很难说谁比谁好。但是在面对超高吐吞量的场景下,异步处理就比同步处理有比较大的优势了,这就好像一个人不可能同时接打很多电话,但是他可以同时接收很多的电子邮件一样。同步调用虽然让系统间只耦合于接口,而且实时性也会比

2021-08-18 21:52:44 284

原创 分布式系统之容错设计-故障隔离

容错设计又叫弹力设计,其中着眼于分布式系统的各种“容忍”能力,包括容错能力(服务隔离、异步调用、请求幂等性)、可伸缩性(有 / 无状态的服务)、一致性(补偿事务、重试)、应对大流量的能力(熔断、降级)。可以看到,在确保系统正确性的前提下,系统的可用性是弹力设计保障的重点。故障隔离隔离设计对应的单词是 Bulkheads,中文翻译为隔板。但其实,这个术语是用在造船上的,也就是船舱里防漏水的隔板。一般的船无论大小都会有这个东西,大一点的船都会把船舱隔成若干个空间。这样,如果船舱漏水,只会进到一个小空间里

2021-08-17 20:22:25 2106

原创 分布式系统关键技术:全栈监控

首先,我们需要一个全栈系统监控的东西。它就像是我们的眼睛,没有它,我们就不知道系统到底发生了什么,我们将无法管理或是运维整个分布式系统。所以,这个系统是非常非常关键的。这个监控系统需要完成的功能为:全栈监控; 关联分析; 跨系统调用的串联; 实时报警和自动处置; 系统性能分析。多层体系的监控所谓全栈监控,其实就是三层监控。 基础层:监控主机和底层资源。比如:CPU、内存、网络吞吐、硬盘 I/O、硬盘使用等。 中间层:就是中间件层的监控。比如:Nginx、Redis、Ac

2021-08-16 21:55:33 356

原创 分布式系统的冰与火与技术栈

最近在极客时间看到一个课程叫《左耳听风》,第一反应是叫这个名字,太不突出重点了,能好卖吗。但当了解作者后,发现是我错了。作者好牛比啊。所以要感受下骨灰级程序员的魅力。先从分布式系统入手学习吧。分布式系统架构的冰与火首先,阐述一下为什么需要分布式系统,而不是传统的单体架构。这个其实对于大部分人来说已经不是问题了。但还是阐述下吧,使用分布式系统主要有两方面原因。 增大系统容量。我们的业务量越来越大,而要能应对越来越大的业务量,一台机器的性能已经无法满足了,我们需要多台机器才能应对大规模的应用场景。

2021-08-15 21:14:47 164

原创 golang字符串转Time类型问题小记

最近在做项目中,遇到了golang 字符串转Time类型的问题。调研后发现golang 提供了俩种方式,即time.Parse 跟 time.ParseInLocation。俩种方式 差距很大,用不好小心踩坑。先上代码:结果:不难发现,俩种方式转换后的时间戳是不一样的。结果是差了8个小时。导致这个的原因就是时区的问题。看下俩个函数的作用:time.Parse把时间字符串转换为Time,时区是UTC时区。 time.ParseInLocation可以根据时间字符串和指...

2021-08-13 21:03:39 2125

原创 领域驱动设计-day7

通过之前的学习,对DDD从设计到开发已经有了一定的了解。DDD作为指导微服务建模的指南,讲了从战略设计 到战术设计的方法。但没有讲解微服务拆分,跟设计的原则。今天就学习下微服务拆分的原则,同时也是领域设计的最有一节。一、微服务设计和拆分要坚持哪些原则?微服务设计原则微服务设计原则中,如高内聚低耦合、复用、单一职责等这些常见的设计原则在此就不赘述 了,主要强调下面这几条: 第一条:要领域驱动设计,而不是数据驱动设计,也不是界面驱动设计。 微服务设计首先应建立领域模型,确定逻...

2021-08-12 21:38:15 106

原创 领域驱动设计-day6

今天开始学习,如何讲前期设计的领域对象转换为代码工程。一.代码模型:如何使用DDD设计微服务代码模型?之前的学习,讲到过一共是有三种架构模式:1.DDD分层架构。2.整洁架构。3.六边形架构。虽然是三种,但是感觉区别并不大,所以今天就围绕DDD分层架构进行代码设计。DDD分层架构首先先回顾下ddd分层架构。代码模型一级目录结构微服务一级目录是按照 DDD 分层架构的分层职责来定义的。从下面这张图中,我们可以看 到,在代码模型里分别为用户接口层、应用层、领域层和基础层,建.

2021-08-11 21:16:59 318

原创 领域驱动设计-day5

今天开始进入实战篇,实战会讲如何运用事件风暴进行建模,以及代码演示等。一.领域建模:如何用事件风暴构建领域模型?

2021-08-10 21:28:43 154

原创 领域驱动设计-day4

一.微服务架构模型:几种常见模型的对比和分析上节学习了DDD的分层架构,除了这种,还有整洁架构以及六边形架构。首先看下整洁架构。整洁架构整洁架构又名“洋葱架构”或者clean架构 在整洁架构里,同心圆代表应用软件的不同部分,从里到外依次是领域模型、领域服务、应 用服务和最外围的容易变化的内容,比如用户界面和基础设施。 整洁架构最主要的原则是依赖原则,它定义了各层的依赖关系,越往里依赖越低,代码级别 越高,越是核心能力。外圆代码依赖只能指向内圆,内圆不需要知...

2021-08-09 22:11:13 178

原创 领域驱动设计-day3

今天主要是学习DDD第七讲分层架构一.DDD分层架构:有效降低层与层之间的依赖 首先看下整体的架构图1.用户接口层 用户接口层负责向用户显示信息和解释用户指令。这里的用户可能是:用户、程序、自动化 测试和批处理脚本等等。 2.应用层 应用层是很薄的一层,理论上不应该有业务规则或逻辑,主要面向用例和流程相关的操作。 但应用层又位于领域层之上,因为领域层包含多个聚合,所以它可以协调多个聚合的服务和 领域对象完成服务编排和组合,协作完成业务操作。 此外,应用层也是

2021-08-08 22:20:04 144

原创 领域驱动设计-day2

今天主要学了极客时间课程的第五,第六章。下面是今天的记录与思考。一.聚合和聚合根:怎样设计聚合? 举个例子。社会是由一个个的个体组成的,象征着我们每一个人。随着社会的发展,慢慢出 现了社团、机构、部门等组织,我们开始从个人变成了组织的一员,大家可以协同一致的工 作,朝着一个最大的目标前进,发挥出更大的力量。 领域模型内的实体和值对象就好比个体,而能让实体和值对象协同工作的组织就是聚合,它 用来确保这些领域对象在实现共同的业务逻辑时,能保证数据的一致性。 聚合...

2021-08-07 21:17:00 127

原创 领域驱动设计-day1

今天重新回到领域驱动设计学习上来,这次主要是通过学习极客时间的课程,感觉讲的还不错,所以接下来要把这个课程通读一遍,并记录下主要内容,供以后翻阅学习。今天主要学习了前五讲,下面记录下今日学习笔记。1.学好DDD,可以做什么? 在没有DDD之前,划分微服务,大多是都是根据经验,或者业内的一些案例。缺少一个好的指导方法,直到DDD出现后,我们就可以按照DDD的方法论进行业务领域的建模,微服务的分界。所以说 学好了DDD。我们在做业务架构的时候,就可以按照DDD的方法进行业务建模...

2021-08-06 22:06:08 110

原创 Redis分布式锁

今天看到一盘文章是写reids分布式锁的,感觉写的还可以。同时也发现了自己在之前使用redis锁的时候的一些问题,所以总结下redis作为分布式锁使用的注意事项。一、原子性 因为在设置redis key的时候,同时要设置过期时间。我们要保证 设置 key成功的时候,设置过期时间也要成功, 不然就可能出现死锁的可能。这里我们可以使用 lua 脚本,把这俩个命令封装在一起,一起发送到服务端,保证原子性。二、锁互斥机制 客户端1加了锁,在客户端2过来加锁的时候,要保证客户端...

2021-08-05 19:34:28 110

原创 领域驱动设计之概念篇

领域驱动设计之所以晦涩难懂,个人感觉是名词太多,而且晦涩难懂,今天就整体梳理下 这里面的名词,并结合具体的例子加强理解。一、领域与子域 不管是在软件开发中还是在研究其他问题的时候,我们都可以把复杂问题根据某些特性拆分成多个子问题,每个问题只在特定的范围或区域内研究,这个特定的范围或区域就可以称为领域。 当一个领域的问题还是很复杂的时候,我们可以继续拆分,拆分出来的子领域研究的范围或区域就称为子领域。 例如,以公司为例子,公司拆分了好多业务线,从K0到K5以及其他的...

2021-08-04 22:08:33 167

原创 领域驱动设计之CQRS

1.概念CQRS全称:Command Query Responsibility Segregation ,中文名:命令查询与职责分离2.什么是CQRSCQRS 将系统中的操作分为两类,即「命令」(Command) 与「查询」(Query)。命令则是对会引起数据发生变化操作的总称,即我们常说的新增,更新,删除这些操作,都是命令。而查询则和字面意思一样,即不会对数据产生变化的操作,只是按照某些条件查找数据。CQRS 的核心思想是将这两类不同的操作进行分离,然后在两个独立的「服务」中实现。这里的「

2021-08-02 21:25:11 461

原创 CAP理论

今天重学下cap理论,加强下理解。一、分布式系统的三个指标1998年,加州大学的计算机科学家 Eric Brewer 提出,分布式系统有三个指标。Consistency Availability Partition tolerance它们的第一个字母分别是 C、A、P。Eric Brewer 说,这三个指标不可能同时做到。这个结论就叫做 CAP 定理。二、Partition tolerance中文名叫 分区容错,意思是 区间通信可能失败。比如,一台服务器放在中国,另.

2021-08-01 14:54:26 104

原创 golang for 循环创建协程问题

golang里,在for循环里面起协程,如下代码。会输出for循环的最后一个数,或者参杂有不确定的其他数字。原因如下:golang是值拷贝传递。for循环很快,协程创建需要的时间大于for循环的时间。因为协程创建 需要进行 堆栈分配,上下文准备,以及与内核态的线程进行映射工作等。所以在协程创建好后,大家同时去访问tmp变量,这个时候 tmp 就被多个协程共享了,导致取到的值都一样了。解决方案:就是使用golang的闭包函数。给匿名函数增加入参,因为是值传递,所以每次for创建一个协...

2021-07-30 22:15:42 2126

原创 ER图 咋画

一、什么是E-R图? E-R图又称实体关系图,是一种提供了实体,属性和联系的方法,用来描述现实世界的概念模型。通俗点讲就是,当我们理解了实际问题的需求之后,需要用一种方法来表示这种需求,概念模型就是用来描述这种需求。二、基本元素 实体:实际问题中客观存在的并且可以相互区别的事物称为实体。实体是现实世界中的对象,可以具体到人,事,物。比如:最近在做的活动实体,任务实体。 属性:体所具有的某一个特性称为属性,在E-R图中属性用来描述实体。比如:活动有活动co...

2021-07-23 23:06:02 3997 2

原创 如何画流程图 2021.07.19

概念流程图可以简单地描述一个过程,是对过程、算法、流程的一种图像表示,在技术设计、交流及商业简报等领域有广泛的应用。优点采用简单规范的符号,画法简单; 结构清晰,逻辑性强; 便于描述,容易理解。主要符号基本要求(1)直观易懂:使用的元素要尽可能地少,表达的信息要尽可能地清晰。(2)布局清晰:要从上至下、从左至右进行绘图,确保脉络清晰,避免流线交叉。(3)逻辑完整:不要遗漏重要的流程,同时对有描述的流程必须要完整。(4)用户视角:流程图要能够反映用户的真实需求,同...

2021-07-19 22:16:05 154

原创 UML状态图 2021.07.18

概述UML状态图主要用于描述对象具有的各种状态、状态之间的转换过程以及触发状态转换的各种事件和条件。UML 状态图的目的:UML 状态图可以捕获对象、子系统和系统的生命周期,可以告知一个对象可以拥有的状态,并且事件(如消息的接收,时间的流逝、错误、条件为真等)会怎样随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标志状态和复杂行为的类;该图可以确定类的行为以及该行为如何根据当前的状态而变化,也可以展示哪些事件将会改变类的对象的状态。UML 状态图怎么画状态图是用来.

2021-07-18 17:54:09 1558

原创 UML时序图学习 2021.07.17

什么是时序图时序图(Sequence Diagram),又名序列图、循序图,是一种UML交互图。它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。纵向代表发生的时间,横向代表参与的对象。我们工作中使用时序图大部分场景就是描述一个复杂场景的系统交互过程。时序图中的元素角色系统角色,可以是人或者其他系统,子系统。以一个小人图标表示。对象对象位于时序图的顶部,以一个矩形表示。对象的命名方式一般有三种: 1 对象名和类名。例如:华为手机:手机。 2 只显示类名...

2021-07-17 22:48:14 294

原创 UML学习概述 2021.07.16

写在前面:最近在做技术设计,自己画的时序图,发现好多不对的地方,以及对业务的抽象能力也需要加强。同时在领导的建议下,感觉自己很有必要加强下这方面的训练,首先就从UML开始吧。 今天查了一些关于UML的文章,发现总是零零散散的,不太系统,所以就找了一本书《UML精粹:标准对象建模语言简明指南:第3版》,作者是个外国人 Fowler, M。本书是一本思想大于教条的好书,作者的目标就是:寻求UML最有用的部分,而且就告诉你这部分。闲言少叙,正式开始。 什么是UML? ...

2021-07-16 22:02:29 139

空空如也

空空如也

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

TA关注的人

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