UML系统建模1概述1.1课程概述收集UML和一些相关主题复习UML相关符号和概念建模效率和表达架构思想1.2什么是UMLUnifiedModelingLanguage统一建模语言，又称标准建模语言。是一种用于软件密集型系统可视化建模的语言。语言是表达思想的符号约定。1.3UML的发展和版本建模语言出现于1970年代，80年代后期开始迅速发展。有超过50种建模语言。后来，Rumbaugh于1994年加入了Booch的Rational公司，他们一起研究了Aunifiedmethod一年后，UnifiedMethod0.8诞生了。经过三年的共同努力，1996年发布了UML0.9和UML0.91。自此，UML创始人Booch等人邀请了IBM、惠普、微软、甲骨文等计算机行业的知名人士和公司对UML进行点评，听取他们的意见。1997年1月，Rational向OMG（对象管理组织）提交了UML1.0。1997年11月，OMG宣布接受UML并承认它为标准建模语言。1998年发布UML1.21999年发布UML1.32003年3月发布UML1.52004年发布UML1.5UML2.01.4UML能做什么从命名分析：统一，建模，语言统一：没有规律，它规定了一个标准，一个约束，让大家的表达变得一致。它被OMG（对象管理组织）认可。OMG是一个国际性、开放会员制、非营利性的计算机行业标准协会，成立于1989年，是软件行业的标准认证机构。包括客户、领域专家、分析师、设计师、程序员、测试工程师和培训师等。UML成为他们工作中的统一沟通工具，充分理解和表达他们的关注点。建模：对复杂的业务系统进行建模，即建立软件系统楷模。UML的创始人之一Booch曾经用建造一座摩天大楼来描述UML的必要性。在一个简单的系统中，它是可有可无的，而当系统复杂或庞大到一定程度时，建模和文档化就成为系统周期中非常重要的一环。语言：面向对象思想的表达。彼此之间的沟通工具。根据特定规则和模式组织的符号系统。1.5学习UML的意义团队或架构设计必须相互交流，交流语言是一种技能，不一定会用到，但是作为架构师，应该知道还有其他的表达方式，但是习惯之后它，UML真的很方便Easeofuse1.6关于UML的争议观点一：UML鸡肋，远不是程序员真正需要的设计工具。只有少数程序员使用这个工具来交流思想，而不是在实际工作中使用它。观点二：UML设计相当严谨和全面。在面向对象的系统架构上，你可以轻松表达所有你想表达的想法。美是无可替代的。个人观点：学一门技能和工具并不难，只要能在需要的时候使用，技能不至于过人。1.7避免形式化。不要过分将UML神化为表达思想的工具。照原样使用，不要刻意使用。2理论2.1关系关系是现实世界中事物之间关系的符号表达。大致有6种。2.1.1泛化的定义：Java中extends可以在接口之间使用，也可以在一个方向的父子类之间使用，箭头指向父类，比如Tiger指向Animal代码：//classpublicclassAnimal{}publicclassCatextendsAnimal{}//interfacepublicinterfaceAction{}publicinterfaceJumpextendsAction{}2.1.2实现定义：Java实现，箭头指向单向接口，如果Tiger扩展了Sleep接口，然后箭头指向Sleep代码：publicinterfaceJump{}publicclassTigerimplementsJump{}2.1.3依赖（Dependency）定义：某个类或对象实例依赖于另一个，对方在其关键方法中使用.如果属性发生变化，对方可能会受到影响。一般来说，它是单向的。例如，动物依赖食物。eat(Food食物)类比更像是表结构中的外键代码：方法参数、局部变量2.1.4关联(Association)定义：是拥有关系，双方不一定属于同一类型thing，指向owner的箭头可以是单向的也可以是双向的，比如Tiger和Zookeeper都是类比表结构，更像是有一个中间表关系代码：成员变量2.1.5聚合（Aggregation）定义：单向，从空心菱形开始的箭头，箭头指向一个很弱的owner所有权关系，A可以拥有B，但并不是没有B，group和Individual的关系，比如一个group包括组成员代码：成员变量，多为集合2.1.6组合定义：单向，实心菱形为起点，箭头指向子模块整体与部分的关系，A由B组成，没有B是不完整的。单向，比如人和肢体的关系代码：成员变量，多为集合注意接口组合和聚合，聚合就是聚合，组和个体。组合即合成，要注意整体与部分的关联和依赖。一般来说，联想是同级别的关联，而且这种关联会长期存在。依赖是一种需求关系。一方需要依赖另一方，这可能会随着另一方的变化而变化。关系强弱顺序：Inheritance=Implementation>Composition>Aggregation>Association>Dependency2.2图2.2.1概述UML中的图形很多，按类型分为结构图和行为图，其中最常见的是常用的和典型的有9种，下面分别介绍。用例图：从用户的角度描述系统功能。类图：描述系统中类的静态结构。对象图：系统中多个对象在某一时刻的状态。状态图：描述状态到状态的控制流程，用来表达系统状态的变化。活动图：描述业务实现用例的工作流程，强调动作之间的联系。顺序图：对象之间的动态协作关系，强调对象发送消息的顺序协作图：描述对象之间的协助关系，强调对象之间的协作关系组件图：描述系统各组件的静态视图及其相关关系部署图：定义系统中软硬件的物理架构2.2．2类图1)解释面向对象系统建模中最常用和最重要的图，是定义其他图的基础。主要用于展示系统中的类、接口和静态结构以及它们之间的关系。模型描述细化了相关的属性和操作。它是业务模型的面向对象过程和对系统的约束。可直接构建可执行代码，但实际使用场景比较少。2）可用元素类：接口：关系：可以使用上面的6个关系。3)实例2.2.3对象图1)说明对象图和类图反映的是系统的静态过程，但表达的是一个实际的场景。对象图一次显示对象和对象之间的关系。可以看作是类图的快照。对象图是类图的实例，因此使用与类图几乎相同的符号。2）可用元素对象：3）关系对象图是对象运行在某个时间节点的镜像，所以关系比较简单，描述的是类和类的实例之间的关系。不涉及接口关联：对象之间存在关联，如用户、订单依赖：对象实例之间的依赖关系，如商品对象依赖店铺4)图2.2.4组件图1)说明在UML1.1中，组件图用于描述系统的物理组件。包括文件、可执行文件、库等。UML2侧重于组件之间的关联（使用什么接口，通过什么端口通信），强调通过接口描述组件行为。对于后端，组件图更适合SOA架构，微服务架构，它描述了整个系统的结构和子系统之间的通信方式。对于前端来说，组件图适用于在使用react、vue等组件化的前端技术框架时表达组件的设计。例如，一个页面会有一个Skeleton组件，它包括导航组件、列表组件等。2）可用元素组件：描述系统的一个组件，一个完整的模块或单元，可以独立服务，如订单服务，k8s中的一个podComponent：组件可以细分为多个子模块。端口：组件必须暴露相应的端口对外提供服务。例如httprest服务默认的80接口：组件/组件之间的一种约定，子提供者和需求者同时展示某个组件提供的功能3）关系泛化：用于存在于之间interfaces组件之间也可能存在父子关系，但使用的实现相对较少：接口与其实现者（提供服务的组件）之间的关联：需要链接/连接器，接口与调用者（提供服务的组件）之间需要接口)4)图2.2.5部署图1)说明了显示运行时处理的节点和节点上存在的组件配置的图。阐述了软件在实际应用中与其运行环境的关系，描述了软件部署在硬件上的具体方式。2）可用元素节点：在早期的单实例MVC架构下，一个节点可以看做一个物理服务器。在微服务和容器化下，大部分物理服务器都包含在编排管理中。docker实例在物理节点上由系统自由调度，组件无法锁定。在一个固定的物理节点上，这个环境中的一个节点可以理解为一个容器，或者k8s中的一个pod。组件实例相当于组件中的实例化，类比类和对象3）关系依赖：发生在组件之间，比如用户组件依赖于订单组件关联：节点关联，发生在节点之间，比如应用服务器需要与mysql数据库关联4)图例2.2.6用例图1)说明用例图是一种用来描述系统功能的技术。表示系统中用例、参与者及其关系的图，主要用在需求分析阶段，比产品文档更接近用例图，相当于从用户的角度对整个系统进行描述和建模，分析系统的功能和行为。2)可用元素参与者：参与者的数量与使用系统的人的角色一样多。用例：参与者可以做的事情3）关系泛化：参与者之间可以泛化，比如用户和普通会员；usecases也可以泛化，比如用户管理和密码修改关联：发生在参与者和用例之间，说明这个角色有哪些用例（行为）依赖关系：发生和用例之间，比如登录依赖于注册丢失的信息，也有一定的区别。下面单独类比时序图1）说明时序图主要用来按照交互发生的先后顺序来展示对象之间的消息或行为传递。时序图可以直观地表达整个过程，类似于流程图，但流程图更多的是业务逻辑，而时序图是系统面向对象建模后，对象对应的交互过程。倾向于开发者的观点。2）可用元素对象：提供功能和交互的类的实例参与者：同类型用例的参与者，大部分是一个流程的起始点Timeline：整个交互过程中对象的生命周期消息：对象需要发送和返回的消息可以发送给自己供外部参考：序列图可以引入一个外部片段作为参考，或者与序列中当前图的元素参与交互片段：包括片段的序列进入段管理，段就像一个原子。一些整体的行为，比如循环3)Relationships不会使用6大关系，而是使用消息来交互。它代表信息流。4)LegendCollaborationDiagram(1.4)/CommunicationDiagram(2.0)1)ExplanationCollaborationDiagram类似于SequenceDiagram，都是用对象之间的交互来描述用例。两人的看法略有不同。时序图强调交互的时间顺序，协作图强调交互的空间结构。2）AvailableelementsParticipants：系统参与的角色Objects：时序图，系统中实例化的对象关联：Association对象之间的关系消息：Existingattachedtoassociations，承载对象之间传递的信息3）Relationships不是6大关系将被使用，消息将被用于相互交互。它代表信息流。4)Legend两个交互图可以相互转化。类比如下：2.2.8状态机状态机分为状态图和活动图。状态图1)基于事件响应描述实体的动态行为，它有两个方面的价值，一个是反映对象可能的状态，另一个是这些状态如何流动，需要什么样的条件进入什么样的状态。2）可用元素状态：在某个时间点，对象的状态。Transition：连接状态之间，因为状态可以相互改变。分支/汇合点：状态变化过程中可能会出现分叉或交集，比如确认收货后，双方相互评价产生分叉起点/终点：状态的起点和终点同步点：当需要多个分支状态时使用。多用于并行协同处理的状态流。例如，完成互评后，订单视为终止。3）该关系只是一种传递关系，表示状态之间的变化。4)Legend活动图1)说明活动图用于业务流程构建模型是内部活动的表达和活动之间的动作流转。活动图类比流程图：活动图有分支和交叉点，可以表示并行存在的活动。不同的是，状态图强调的是行为的结果（下一个状态是什么），而活动图关心的是行为的动作（接下来要做什么）。两者可以理解为穿插配合，一动一静，活动可能会触发下一步不同的状态。2）可用元素活动：表示系统或对象内部可能发生的某种动作。对象：活动的创建者，或交互者。判断，根据条件不同流同步：并行流下的集合，与流程图不同的地方Start/end：活动的开始和结束泳道：UML活动图中的分组活动，同一类型的活动在一条泳道中3）关系只有flow，即activity的跳转，表示下一个activity是什么4）图3实用篇3.1常用工具3.1.1RationalRose老牌子，名牌，史上最著名的UML产品，对于大多数情况，很多人把他等同于UML工具。需要说明的是，自从Rational被IBM收购后，RationalRose就成为了历史。作为UML1.4标准的产物，现在没有升级，但是已经足够了。它的替代品是IBM的其他产品，例如IBMRSA。3.1.2RSAIBM?Rational?SoftwareArchitect是IBM的旗舰产品，是一种用于端到端软件交付的高级综合应用程序设计、建模和开发工具。通过与其他IBM产品协调，它支持软件开发的全生命周期开发。但它也有缺点，繁琐复杂（大公司产品通病？？？）3.1.3EnterpriseArchitectSparxSystems的旗舰产品。它涵盖了系统开发的整个周期，包括业务流程分析、用例需求、动态模型、组件和布局、系统管理、非功能需求、用户界面设计、测试和维护，以及开发类模型。总之，基本可以满足你的需求，而且价格便宜。性价比之选。3.1.4StarUML开源的UML开发工具，是韩国公司开发的产品。用Delphi写的，真是个大神。需要付费，网站提供购买注册码，小巧简单好用，和rose比起来更加明显。3.1.5VISIOVISIO可以理解为一个通用的绘图工具。它有各种常见的图形。从VISIO2000版本开始涉足从软件分析设计到代码生成的所有功能。从绘图的角度来说，它有着无可比拟的优势，UML图标只是其中的一小部分。优点是可以很好的兼容MicrosoftOffice产品。图片可以直接复制或嵌入到WORD文档中。但是代码的生成更多的是支持微软自己的产品，比如VB、C#、mssql等（微软一贯的风格）。如果你只画UML图，表达大量的word文档，它就可以满足你。3.1.6PowerDesignerSybase的企业建模和设计解决方案。采用集成业务和IT的模型驱动方法可以帮助部署有效的企业架构，并为研发生命周期管理提供强大的分析和设计技术。集成多种标准数据建模技术并与IDE集成，通常以Eclipse插件的形式。PD给人更多的是数据库建模技术的印象，但它可以完成UML所有的建模操作，映射到数据库和代码层面。并提供对60多种关系型数据库的连接支持。3.1.7总结以上工具的优缺点。大家可以根据自己的实际情况和爱好来选择，基本涵盖软件建模的完整周期。UML只是它们的一部分功能。其中任何一个都可以满足你学习和工作的UML建模。使用需求3.2订单建模实践3.2.1B2C交易用例图用例图从订单系统的用户角色出发，反馈订单系统中有哪些人，他们可以做什么1）业务需求：买家：浏览产品、下单、支付、收款卖家：开店、订单确认、发货、产品维护双方：退货、换货、评价、收款3.2.2订单模块类图订单类图从业务模型出发，使用对象-面向思维，并将订单业务中的模型抽象为个体对象1）元素：Person类：Seller，Buyer，User商品类：Shop，Product交易链接类：Cart，Order，Invoice，AliPay，WeichatPay，ICBCPay...交易链接接口：PayPromotion相关类：DiscountPromotion、ReductionPromotion...促销接口：Promotion2)关系：Association：Order→Seller、Buyer、Pay；商店→卖家依赖：订单→购物车→促销，发票；组合：商店→产品聚合：购物车→产品概括：买方、卖方→用户实施：DiscountPromotion、ReductionPromotion→Promotion；支付宝、微信支付、工银支付→支付宝3.2.3下单时的对象图对象图表达了下单时系统中存在的对象以及对象之间的关系。对象有实际属性值1）Element：与类图一致，但接口将不复存在，成为实际实现类Cart生命周期结束，Invoice还没有诞生，Product，Promotion都依附在objectonorder属性有实际值，不再是泛化类属性的概念2）关系：对象变成实例链接（Instancelink），不再使用泛化和实现。弱类型可以使用依赖，如Order、discountedPromotion3.2.4B2C订单支付时序图时序图体现了各个对象如何协作交互，从下单到完成支付期间，相互之间需要传递什么消息。1)元素特征：买家对象：Product,Cart,Order,Promotion,Pay,AliPay(external)2)时间序列前向：Buyer→filter→Product→add→Cart→promotionsettlement→Promotion→order→Order→pay→Pay→跳转→支付宝循环：Buyer←Notification←Order←Billing←Pay←Callback←AliPay循环：Cart←→商品增删改型。但是协作图体现的是交互关系，比如展开的时序图1）元素，时序图person:Buyer对象：Product,Cart,Order,Promotion,Pay,AliPay（外部）2）交互，与时序关联图Message3.2.6B2B先付款及发货状态示意图以B2B先付款业务模型下订单对象流转状态为例，实现业务状态展示1）订单起始订单的状态值元素会同步结束2）流通开始→合同已生成→付款已付款→提货单已生成→货物已发货→验货验票→待评价→分行→买家已评价，卖家已评价→同步→结束3.2.7B2B先付款后货交易中，双方应该进行哪些活动或操作，体现在通过活动图的建模1)元素泳道：Buyer,Seller,Manageractivities(Buyer):generatecontracts,payofgoods,inspectiongoodsandchecktickets,Buyer'sevaluationactivity(Seller):generatedeliverynote,delivergoods,seller's评估活动（经理）：仲裁判断：是否有异议2）流程开始→生成合同→货款→生成提货单→发货→核对发票货物→判断（是否有异议？）→否→分公司→买家，卖家评价→同步→终审异议→是→仲裁→终止，相当于定义了一套约定。1)要素Order:create(Cart),open(Pay)Cart:addProduct(Buyer),removeProduct(Buyer),settle(Buyer)Promotion:discount(Cart)Pay:pay(Buyer)3.2.9订单中心部署图如何将订单中心部署到服务器？部署图的职责就是完成这部分。在docker容器化编排和云环境中，部署图变得不那么精确。节点可以理解为一个docker容器或者k8s等编排工具中的一个pod，组件不再固定在某个节点，而是由调度器动态调度，去中心化部署。1）元素节点：App1、App2、App3，假设有3个；mysql数据库，假设1主2从组件：Order,Cart,Pay,Promotion2）关系组件离散分布在3个AppApps关联mysqlmysql主从作为依赖3.3总结一切都是工具，适合自己的才是最好变通，不要拘泥于规则，规则是死人是活的，表达思想才是目的，一切都是为了能把自己的思想表达清楚，这也是语言的精髓，不要只是画图对于绘图，UML不是必需的，但有了它，您的建筑工作将变得更加顺畅。希望UML能成为你们架构工作的利器，提高效率，解决问题。谢谢！本文由传智教育博学谷-荒野建筑师教研团队发布。转载请注明出处！
