Unified Modeling Language 统一建模语言,又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。语言,也就是一个表达思想的符号约定。
从命名上分析:统一、建模、语言
统一:没有规矩不成方圆,它指定了一种标准,一种约束,使得大家的表达变得一致。它被OMG(Object Management Group)所认可。
OMG是一个国际化的、开放成员的、非盈利性的计算机行业标准协会,该协会成立于1989年,他是软件行业中一个标准的认可。包括客户、领域专家、分析师、设计师、程序员、测试工程师及培训人员等。UML成为他们工作中统一的沟通工具,用于充分理解和表达自己所关注的内容。
建模:复杂业务系统建模,即建立软件系统模型。UML的创始人之一Booch,曾用建一座摩天大楼来比喻UML的必要性。简单系统下,可有可无,系统复杂或大到一定程度,建模和文档成为系统周期里非常重要的一环。
语言:面向对象思想的表达。互相之间的沟通工具。一种按照特定规则和模式组成的符号系统。
观点一:UML是鸡肋,离程序员真正需要的设计工具还差得很远。只有为数不多的程序员使用这个工具交流想法,而没有用在具体工作中。
观点二:UML设计相当的严谨与全面,在面向对象的系统架构上,可以便捷的表达你想要表达的一切想法,优美切无可替代。
个人观点:一项技能和工具,学会并不难,需要的时候能拿来用就好,艺不压身。
不要把UML过度神化
一个表达想法的工具而已
当用则用,不要刻意去套
关系是现实世界中事物与事物之间相互关系的符号表达,抽象到面向对象理念上,大致分为6种。
定义:
代码:
//类
public class Animal {
}
public class Cat extends Animal {
}
//接口
public interface Action {
}
public interface Jump extends Action {
}
定义:
代码:
public interface Jump {
}
public class Tiger implements Jump {
}
定义:
代码:方法参数,局部变量
定义:
代码:成员变量
定义:
代码:成员变量,多为集合
定义:
代码:成员变量,多为集合
一张图涵盖所有的关系:
UML中的图形非常多,按类型分为结构图和行为图,其中,最常用,最典型的为9种,下面分开来介绍。
用例图:从用户角度描述系统功能。
类图:描述系统中类的静态结构。
对象图:系统中的多个对象在某一时刻的状态。
状态图:是描述状态到状态控制流,用于表达系统状态的变化
活动图:描述了业务实现用例的工作流程,强调的是动作之间的衔接
序列图:对象之间的动态合作关系,强调对象发送消息的顺序
协作图:描述对象之间的协助关系,强调对象之间的合作关系
组件图:描述系统各个组件及其相关关系的静态视图
部署图:定义系统中软硬件的物理体系结构
1)说明
2)可用元素
3)实例
1)说明
2)可用元素
3)关系
对象图因为是运行在某个时间节点的对象镜像,所以关系比较单一,描述的是类与类的实例之间。不涉及接口
4)图例
1)说明
UML1.1中,组件图是用来描述一个系统的物理构件。包括文件,可执行文件,库等
UML2 中,关注组件间的关联(使用什么接口,通过什么端口通讯),强调通过接口来描述组件行为
对于后端来说,组件图比较适用于 SOA 架构、微服务架构,描述整个系统的结构以及子系统间的通讯方式
对于前端来说,组件图适合在使用类似 react、vue 这样组件化的前端技术框架时,表达对组件的设计,比如一个页面会有个骨架组件,骨架组件包含了导航组件,列表组件等等
2)可用元素
组件:描述的是系统的其中一个组成部分,一个完整的可独立服务的模块或单元,比如订单服务,k8s里的一个pod
部件:组件内可能细化为多个子模块
端口:组件对外提供服务就必须暴露对应的端口。如http rest服务默认的80
接口:部件/组件之间的一种约定,分提供者和需求者同时展示了某个部件提供出的功能
3)关系
4)图例
1)说明
一种展示运行时进行处理的节点和在节点上存在的组件配置的图。
阐述了在实际应用中软件和它的运行环境的关系,并且描述了软件部署在硬件上的具体方式。
2)可用元素
节点:
早先单实例MVC架构下,节点可以认为是某台物理服务器,微服务及容器化下,物理服务器大多纳入编排管理,docker实例由系统在物理节点见自由调度,组件无法锁定在某个固定物理节点上,这种环境下的node可以理解为一个容器,或k8s中的pod。
组件实例
相当于组件里的实例化,类比于类和对象
3)关系
4)图例
1)说明
用例图是用来描述系统功能的技术,表示一个系统中用例与参与者及其关系的图
主要用于需求分析阶段,和产品文档比较贴近
用例图相当于从用户的视角来描述和建模整个系统,分析系统的功能与行为。
2)可用元素
3)关系
泛化:参与者之间可用泛化,例如用户与普通会员;用例也可用泛化,如用户管理与修改密码
关联:发生于参与者和用例之间,表示该角色可用有哪些用例(行为)
依赖:发生与用例之间,例如登录依赖于注册
4)图例
交互图分为序列图和协作图,两者既可以相互转换而不丢失信息,又存在一定差异。下面分开讲再类比
序列图
1)说明
2)可用元素
3)关系
4)图例
协作图(1.4)/通信图(2.0)
1)说明
协作图与时序图类似,二者都是用对象间的交互来描述用例的。
两者关注角度稍有不同,时序图强调交互的时间次序,协作图强调交互的空间结构。
2)可用元素
3)关系
4)图例
两种交互图可以相互转化,类比如下:
状态机分为状态图和活动图,
状态图
1)说明
2)可用元素
3)关系
4)图例
活动图
1)说明
2)可用元素
3)关系
4)图例
老牌,大名鼎鼎,史上最有名的UML产品,以至于大多数情况下,很多人将他等同于UML工具,需要注意的是,自从 Rational被IBM收购之后,Rational Rose已经成为历史,作为UML1.4标准的产物,现在已经不升级,但是够用。其替代品是IBM的其他产品,如IBM RSA。
IBM® Rational® Software Architect ,IBM的旗舰产品,是一个高级而又全面的应用程序设计、建模和开发工具,用于实现端到端的软件交付。通过和IBM其他产品的协调,支持软件开发的全生命周期开发。但是也有它的缺点,笨重,繁杂(大公司产品的通病???)
Sparx Systems 公司的旗舰产品。它覆盖了系统开发的整个周期,除了开发类模型之外,还包括事务进程分析,使用案例需求,动态模型,组件和布局,系统管理,非功能需求,用户界面设计,测试和维护等。总之你需要的基本都可以满足,价格还便宜。性价比之选。
开放源码的UML开发工具,是由韩国公司主导开发出来的产品。用Delphi写的,是个大神。需要付费,网站提供购买注册码,小巧简单而易用,与rose相比更是明显。
VISIO可以理解为一种通用的画图工具,它具备常见的各种图形,从VISIO2000版本才开始涉足软件分析设计到代码生成的全部功能,单纯从画图角度,有着无可比拟的优势,UML图标仅仅是其中很少的一部分。优点是跟微软的office产品的能够很好兼容。可以把图形直接复制或者内嵌到WORD的文档中。但是到代码的生成更多是支持微软自家的产品如VB,C#,ms sql 等(微软的一贯作风),如果仅是画UML图和大量的word文档表达,它可以满足你。
Sybase的企业建模和设计解决方案。采用模型驱动方法,将业务与IT结合起来,可帮助部署有效的企业体系架构,并为研发生命周期管理提供强大的分析与设计技术。将多种标准数据建模技术集成一体,并与IDE集成,典型的如Eclipse 插件形式。PD更多给人的印象是数据库建模技术,但是它可以完成UML的所有建模操作并映射到数据库和代码层面。并提供60多种关系数据库的连接支持。
用例图从订单系统使用人角色出发,反馈订单体系里面有哪些人,可以做哪些事情
1)业务需求:
订单类图从业务模型出发,用面向对象思想,订单业务中的模型抽象为一个个对象
1)元素:
2)关系:
关联:Order→Seller,Buyer,Pay;Shop→Seller
依赖:Order→Cart→Promotion,Invoice;
组合:Shop→Product
聚合:Cart→Product
泛化:Buyer,Seller→User
实现:DiscountPromotion,ReductionPromotion→Promotion;AliPay,WeichatPay,ICBCPay→Pay
对象图表达的是下订单的时刻,系统存在的对象及对象之间的关联关系。对象具备了实际的属性值
1)元素:
2)关系:
序列图反应下单到支付完成这段时间里,各个对象怎么协作和交互,互相之间需要传递什么消息。
1)元素
2)时间序列
协作图同序列图类似,可以由序列图转化而来。但是协作图反映的是交互关系,像是铺开的时序图
1)元素,同时序图
2)交互,同序列图
以B2B先款后货业务模式下,订单对象的流转状态为例,实现业务状态展示
1)元素
2)流转
在先款后货的交易中,双方都要做哪些活动或者说操作,通过活动图建模体现
1)元素
2)流程
界定构成订单服务的各个对象以及他们之间的可用接口,相当于定义了一组约定。
1)元素
将订单中心如何部署到服务器?部署图的职责就是完成这部分的内容。在docker容器化编排和云环境下,部署图变得不那么的确切。node可以类比理解为docker容器或者是k8s等编排工具中的pod,而组件也不再固定在某个node中,而是由调度器动态调度,分散部署。
1)元素
2)关系
一切皆工具,适合你的就是最好的
灵活变通,不要拘泥规矩,规矩是死的人是活的
表达思想才是目的,一切都是为了能说清楚你的想法,这也是语言的本质
不要为了画图而画图,UML不是必须的,但是有了它你的架构工作会变得更顺畅
希望UML能成为你架构工作的利器,提升效率,解决问题。Thanks!
本文由传智教育博学谷 - 狂野架构师教研团队发布 转载请注明出处!
|