申请了域名怎么做网站,成立公司的条件,wordpress mysql版本,wordpress 电影解析更多示例图片可以参考#xff1a;#xff08;除了常见的流程图#xff0c;其他都有#xff09; 概念#xff1a;类图 静态#xff1a;用例图 动态#xff1a;顺序图状态图活动图 1、【面向对象】UML类图、用例图、顺序图、活动图、状态图、通信图、构件图、部…更多示例图片可以参考除了常见的流程图其他都有 概念类图 静态用例图 动态顺序图状态图活动图 1、【面向对象】UML类图、用例图、顺序图、活动图、状态图、通信图、构件图、部署图 2、【软考】数据流图数据库设计UML建模复习指南 3、【高项】信息化与信息系统第4版教材第1-5章计算机科学知识 文章目录 1、概念建模 领域建模2、需求分析—描述功能用例图、流程图2.1 业务用例图、系统用例图2.2 流程图 3、概要设计—静态模型类图4、详细设计—交互关系序列图状态机活动图*4.1 业务序列图4.2 分析序列图4.3 状态图4.4 活动图 5、开发实现部署图附UML2.0中的14种图 1、概念建模 领域建模
问题 团队内以及团队外日常进行沟通需求和对齐设计往往采用当面沟通白板沟通等原始的方式。这些方式存在没有留下痕迹领域知识表述不充分难以理解等问题。
改进最佳实践为领域建模通过统一交流语言达到对齐认知的效果同时沉淀下可分享的知识并持续迭代和完善做到随时能以可视化的方式进行呈现。
领域建模 领域知识领域模型
领域知识 确定实体及其属性描述实体间静态关系描述实体之间的动态关系描述实体生命周期领域模型 建立映射
为什么需要领域建模 领域建模的优点 统一交流语言对齐认知 经验和知识有沉淀能够分享 聚焦可视化 能够持续迭代和完善 业务复杂度 领域自身复杂度技术复杂度 设计方法决定技术复杂度领域本身复杂 设计方法 不合适 复杂度失控 无法理解 无法更改 无法扩展
什么是领域建模 找到问题提高收入 业务建模选定要改进的业务组织组织到底要解决什么业务问题业务用例图现状业务序列图需求(概念建模引入系统)为了解决业务问题所开发系统应提供什么功能和性能改进后的业务序列图、系统用例图、书写用例规约 解决问题降低成本 分析提炼系统内需要封装的核心领域机制。可运行的系统需要封装各个领域的知识其中只 有一个领域核心域的知识是系统能在市场上生存的理由。对核心域作研究可以帮助我们获得基 于核心域的复用。 分析类图、分析序列图、状态图设计将核心域知识和非核心域知识结合最终实现系统。说“代码就是设计”指的是这里说 的“设计”。代码确实是设计但代码不是分析不是需求不是业务建模。要您思考过、表达过上面这些问题就是在建模用文本、UML、其他表示法或自造符号来表 达都可以。而且我相信每一个项目我们都会思考和表达上面这些问题只不过可能是无意识地、 不严肃地在做现在我们要学习有意识地做把它做出利润来。当然使用 UML 来做是目前一个不坏的选择。设计模型实施交付业务代码、测试用例 概念与定义 基于领域知识建立概念模型领域建模的过程就是通过人脑完成分析跨越鸿沟的过程 领域知识建模方法领域建模 领域就是问题域并且大领域可以分解为小领域 领域知识 对现实世界和既有流程的清晰完整认识进入领域内部的深刻认识对历史经验和最佳实践的理解和继承 建模建立映射 建模方法动态建模、静态建模
什么是模型
定义对现实世界人和事务的一种抽象一种形式化表达分类 领域模型 对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身发掘重要的业务领域概念并建立业务领域概念之间的关系 逻辑模型将概念模型具体化带上属性类似LDM数据模型描述含有数据的实体对象如E-R图物理模型针对逻辑模型在具体的物理介质上实现出来如主键联合索引等类似PDM 模型的价值 信息的组织方式统一沟通交流语言对业务的高度抽象承载设计保护和共享知识知识经验沉淀持续学习聚焦可视化 信息传递从抽象到具体 业务角色业务实体联系和协作抽象为了看的见我们需要用一些方法来表示它图是表达领域模型最常用的方式
领域建模的实际应用场景
方案设计CGI与用例有什么关系需求启发、对齐认知到底是干啥数据不对对外合作、树立口碑
2、需求分析—描述功能用例图、流程图 用例50流程10 2.1 业务用例图、系统用例图
用例图是指由参与者Actor、用例Use Case边界以及它们之间的关系构成的用于描述系统功能的视图。是系统的蓝图。
如何画好业务用例图
目的确定开发这个系统的目的业务组织要解决什么问题最佳实践 可以在业务用例图旁边以备注方式说明愿景和涉众利益分析 老板业务研发人员业务产品同学组织要选对业务执行者是组织外的业务执行者是目标组织提供业务价值的期待者目标系统是系统而不是子域中心做的“系统”大部分其实是“XXX系统下”的子域 建模工作流 1业务建模——描述组织内部各系统人脑系统、电脑系统……如何协作使得组织可以为其他组织提供有价值的服务。2需求——描述为了解决组织的问题系统必须具有的表现——功能和性能。3分析——提炼为了满足功能需求系统需要封装的核心域机制。4设计——为了满足质量需求和设计约束核心域机制如何映射到选定平台上实现
系统用例与业务用例的区别 业务用例图主要关注业务流程和业务参与者之间的交互描述了业务参与者如何使用系统来完成业务流程。 它强调的是业务需求和业务流程而不是系统的实现细节。业务用例图通常由业务分析师或业务专家绘制用于与业务参与者交流和确认业务需求以及定义系统的功能和范围。 系统用例图则更加关注系统的实现细节和功能模块之间的关系描述了系统如何响应业务参与者的请求。 它强调的是系统的角色和功能而不是业务流程。系统用例图通常由系统分析师或开发人员绘制用于与技术团队交流和确认系统的设计和实现。
2.2 流程图
流程图是一种图形化的工具用于描述一个过程或系统的流程。它通常由基本的流程图符号和连接线组成用于展示流程中的各个步骤、决策、并发、循环等。
流程图的画法如下
确定流程的起点和终点以及流程中的各个步骤和决策点。使用基本的流程图符号如开始/结束符号、处理符号、决策符号、输入/输出符号、连接线等来表示流程中的各个步骤和决策。按照流程的顺序将各个步骤和决策点用连接线连接起来形成完整的流程图。根据需要添加补充说明和注释以便更好地理解和使用流程图。
流程图的基本符号包括
开始/结束符号用于表示流程的起点和终点。处理符号用于表示流程中的各个处理步骤。决策符号用于表示流程中的决策点通常用“是/否”或“真/假”等条件来表示。输入/输出符号用于表示流程中的输入和输出。连接线用于连接各个步骤和决策点表示流程的顺序和关系。
3、概要设计—静态模型类图 类图150 类图(Class diagram)是显示了模型的静态结构特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。
类之间的几种关系
泛化Generalization、实现Realization、关联Association又分一般关联、聚合、组合、依赖Dependency。各种关系的强弱顺序如下 泛化 实现 组合 聚合 关联 依赖
泛化关系Generalization是继承关系的一种特例表示一个更一般概念的类父类与一个更具体概念的类子类之间的关系。例如猫是动物的一种狗也是动物的一种可以定义一个Animal类作为父类然后猫和狗分别继承Animal类这就是一种泛化关系。组合关系Composition表示整体与部分之间的关系整体对象包含部分对象部分对象不能存在于其他整体对象中。例如一个汽车由引擎、轮胎、座椅等组成这些部分对象只能属于这个汽车不能属于其他汽车。聚合关系Aggregation表示整体与部分之间的关系整体对象可以包含部分对象但部分对象可以存在于多个整体对象中。例如一个班级可以包含多个学生但学生也可以属于不同的班级。关联关系Association两个类之间的关系其中一个类引用另一个类的对象。例如学生和班级之间就是一种关联关系一个班级可以有多个学生一个学生只属于一个班级。依赖关系Dependency表示一个类依赖于另一个类的实现或接口当一个类的方法需要另一个类的对象作为参数时就存在依赖关系。例如一个订单类需要一个货物类对象作为参数就存在订单类对货物类的依赖关系。需要注意的是依赖关系是一种短暂的关系通常只在方法调用的时候存在而不是持续存在的关系。实现关系Implementation一个类实现了一个接口就必须实现该接口中定义的所有方法。例如电视机和洗衣机都可以有一个开关的接口它们都必须实现该接口中的开关方法。继承关系Inheritance一个类继承另一个类的属性和方法被继承的类称为父类或基类继承的类称为子类或派生类。例如猫和狗都是动物可以定义一个Animal类作为父类然后猫和狗分别继承Animal类。
概念建模/对象建模
1、不要过多的考虑实现细节应该是忠于现实还原细节 尽可能多的展开概念名词从现实中来对现实世界和既有流程的清晰、深刻、完整认识不是创造 2、先尽可能展开概念实体然后确定是否为属性3、刚开始不要过度抽象,否则会导致无法表达细节,最后在去泛化时适当抽象4、禁用数据库 ID属性存在 ID等实体间的关系已表达5、多种不同维度的泛化共享数据-关联优先行为变异-泛化优先
如何进行概念建模
概念建模—实体属性 属性: 属性直接描述实体的特征, 是名词属性对实体的所有实例都有意义部分实例有意义的属性放到子实体去当前问题域内不需要再分解重要属性需要在实体里显示出来, 辅助理解模型 检查点: 读一遍: ‘实体名’的’属性名’ 念着通顺属性是简单类型, 不是复杂结构实体和属性不存在一对多的关系多个属性间不要有冗余 概念建模—关系 关系: 主要的关系: 泛化关联聚合, 组合实现依赖观察实体是否整体与部分关系外加两实体的生命周期来区分关联,聚合和组合聚合和组合意味着责任会传递, 责任分配时会先找整体, 再由整体请求部分判断不出啥关系时, 先用关联 检查点: 是整体与部分关系么两个实体生命周期是否相同 概念建模—多重性 多重性: 表示实体之间的数量关系, 1对1, 1对多,多对多角色是实体在关系里的名称, 表示实体在关系中的地位,作用, 职责角色是指定关系上的角色因此先确定关系再谈角色实操中在相同的两个实体之间有多种关系时要标注出角色名 检查点: 多重性在概念类图里需要标出来两实体之间存在不同的关系时需通过关系名和角色名进行区分 概念建模—去泛化 泛化转关联: 去泛化后要保留原来子类通过颜色来体现过程以保留完整信息去泛化时一般会在父类中添加新的属性, 比较典型的是类型属性对于子类的特有属性通过在父类中增加相同的属性来解决去泛化后其它实体和子类的关系也要转移到父类上 检查点: 所有泛化关系是否在建模后期都已经通过转换去掉父类中是否有新增属性体现去泛化过程,子类属性是否丢失其它实体和子类的关系是否有转到父类上 概念建模—压缩 压缩: 将建模中的分析出的实体进行合并1对1和1对多都可以合并压缩可以优化模型的结构和关系提高可读性可维护性可扩展性 检查点: 模型中是否还有两个实体是一对一的关系模型中是否存在实体只和另外1个实体有1对多的关系模型压缩合并后属性是否都在合并到的实体中有体现
4、详细设计—交互关系序列图状态机活动图* 序列图分析200设计100业务50状态机50 4.1 业务序列图
时序图Sequence Diagram又名序列图、循序图顺序图是一种UML交互图。它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。
如何画好业务序列图 业务序列图的目的 描述业务流程的手段是业务建模阶段的产物辅助提炼改进点捕获需求 业务用例 目标组织商家业务执行者用户业务用例购物辅助执行者银行等 要点1改进模式 改进前和改进后的序列图要能体现出使用的改进模式业务序列图仅表达对业务执行者提供的价值且仅仅呈现系统之间的交互如果很多细节交互属于系统用例的交互步骤应该放在分析序列图中 要点2系统与子域 系统来自领域专家对问题的分解业务类系统研发支撑类系统子域对应到问题域XXX治理、XXX自动化等是在线业务研发支撑系统的子域时间它是特殊的外部系统向全世界各种系统发送时间消息 要点3职责与协作 发消息这个场景应画为系统指向自身消息接收者指向系统来查询消息不能出现系统指向人消息是否要画入业务序列图取决于它是否独立提供业务价值如果没有提供独立的业务价值就不需要画入
4.2 分析序列图
分析序列图的意义
动态建模分析系统内实体间如何协作来实现系统价值系统用例静态建模概念精华关联、泛化、压缩
如何画分析序列图
分析序列图–命名系统用例内分析序列图文件使用「用例名」来命名便于管理和识别分析类的命名 边界类用例名UI、外系统名称接口控制类用例名称UC实体类概念实体名称 分析序列图–粒度系统用例内 一个系统用例画一个分析序列图误区1时间只能为系统执行者应该属于另外一个系统用例误区2执行者到UI可以有多个步骤多个步骤并不是多个系统用例 分析序列图–职责分配 类似于业务序列图消息体现类的责任而非数据流动边界类负责输入、输出空值类负责控制流为实体分配责任实体类负责主要业务逻辑 分析序列图–聚合根调度职责分配 分析序列图里的UE是领域概念实体某些耦合关系比较紧的实体可能在设计阶段会被圈为聚合其中接受UC消息的实体会被设定为聚合的聚合根跨聚合的UE调度逻辑一般画在UC上 聚合内的UE调度逻辑一般画在聚合根实体上。 分析序列图–小技巧简化fragment 如果仅仅是前置条件表达可以不使用fragment消息采用“条件:消息内容”即可减少画图成本和理解负担
4.3 状态图
状态图:状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为显示了该实体如何根据当前所处的状态对不同的事件做出反应。
状态图是什么
状态图是一种用于描述系统或对象在不同状态下的行为和转换的图形化表示方法。它由状态、转移和事件三个基本元素组成。状态是指系统或对象在某一时刻所处的状态可以是一个具体的状态、一个过程中的状态或一个概括性的状态。状态通常用圆圈或矩形表示。转移是指系统或对象从一个状态转移到另一个状态的过程。转移通常用箭头表示并标注转移条件和动作。事件是指触发系统或对象状态转移的外部或内部事件。事件通常用菱形表示。状态图可以用于描述各种系统和对象的行为如软件系统、控制系统、通信协议等。在软件开发中状态图通常用于描述对象的生命周期、用户界面交互、状态机等。
状态机职责
状态机只能做实体生命周期管理不做持久化仅仅做实体的属性变更
如何支持重入
什么时候需要重入什么时候不允许重入
4.4 活动图
活动图活动图activity diagram动态图是阐明了业务用例实现的工作流程。
活动图是一种用于描述系统或对象的行为流程的图形化表示方法。它由活动、控制流、决策节点、合并节点等基本元素组成。
活动是指系统或对象的一个行为或操作可以是一个具体的动作、一个过程中的活动或一个概括性的活动。活动通常用矩形表示。
控制流是指活动之间的顺序关系用箭头表示。箭头上可以标注条件或约束。
决策节点是指根据一定条件进行选择的节点用菱形表示。菱形上标注条件。
合并节点是指将多个控制流合并为一个的节点用圆圈表示。
画法如下 确定活动图的目的和范围。 画出活动图的主要流程即活动之间的控制流和顺序关系。 根据需要添加决策节点和合并节点。 细化活动添加子活动和并行活动。 根据需要添加对象和角色标注参与者信息。 根据需要添加注释和说明使活动图更易理解。 审核和修改活动图确保其正确性和完整性。
活动图可以用于描述各种系统和对象的行为流程如软件系统、业务流程、用户操作等。在软件开发中活动图通常用于描述用例场景、业务流程、系统设计等。
5、开发实现部署图 部署图2 部署图描述的是系统运行时的结构展示了硬件的配置及其软件如何部署到网络结构中。 一个系统模型只有一个部署图部署图通常用来帮助理解分布式系统。
部署图是一种用于描述系统或流程中各个组件、模块、节点之间的关系和交互的图形化工具。它可以帮助人们更清晰地理解系统或流程的整体结构和运行方式从而更好地进行设计、优化和管理。
部署图的画法主要包括以下几个步骤 确定系统或流程的组件和节点根据需求和目标确定需要在部署图中展示的系统或流程的各个组件和节点例如服务器、数据库、应用程序、用户等。 绘制组件和节点使用适当的符号和图形将每个组件和节点绘制在部署图中并标注其名称和功能。 连接组件和节点使用箭头或线条等符号将不同组件和节点之间的关系和交互连接起来。例如可以表示数据流、控制流、消息传递等。 标注属性和参数对于每个组件和节点还可以标注其属性和参数例如IP地址、端口号、运行状态等。 完善细节根据需要可以添加其他细节信息例如安全策略、备份策略、性能指标等。
总之部署图的画法需要清晰明了符号简洁易懂同时也需要考虑到系统或流程的实际情况做到准确反映其结构和运行方式。
附UML2.0中的14种图
UML是Unified Model Language的缩写中文是统一建模语言是由一整套图表组成的标准化建模语言。
UML图分为结构图和行为图。表粗的为重点 结构图分为类图、轮廓图、组件图、组合结构图、对象图、部署图、包图。 行为图又分用例图、状态机图、活动图、交互图。 交互图又分为序列图、时序图、通讯图、交互概览图。 参考资料12345
