检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
以新元素方式粘贴到图中; 方式二:选中元素Ctrl+C/V或按住Ctrl键拖动元素弹出弹框,以新元素或者实例化方式粘贴到图中。 父主题: 模型设计
gation关系或父子关系。 在模型图中构建架构关系。 XX模型的元素要与指定的XX模型层次结构保持一致 以逻辑模型为例: 查询逻辑模型架构信息树,右侧操作开关把展示不匹配架构方案的元素打开。 架构信息树构出后 根据错误元素名称查询定位到其所在架构树节点。 查询错误元素与其他元素关系。
部署视图面向系统部署,描述系统的交付、安装、部署的视图,主要解决系统安装部署的问题,描述系统的交付、安装、部署关系。 表1 部署视图 模型类别 描述 交付模型(必选) 交付模型定义的是从构建结果和外部软件一起打包成最终交付给客户的Release Offering的模型设计过程。 部署模型(必选) 部
类型,也支持从当前工程中选择已经定义好的类型。 方法 方法列表:支持快速编辑,存在多条方法可拖动排序。 方法详情:支持自定义,返回类型设可以选择默认的基础类型,也可以手动输入其它类型,也支持从当前工程中选择已经定义好的类型。 父主题: 模型设计
如何表示父子关系 方式一:图中绘制时采用图元嵌套的方式。同时,左侧目录树保持父子结构。 方式二:图中图元设置组合或者聚合关系。如果架构方案中设置其它类型的连线支持构成上下级关系,那么图中绘制对应的连线类型,也可以构成父子关系。 父主题: 模型设计
可以实时看到模型的变化,减少冲突和覆盖,提高建模设计工作的效率。 4+1视图建模 内置华为多年架构设计变更实践成果,支持业界通用UML和4+1视图建模。 模型跨团队共享复用 支持跨工程、跨团队对模型库进行共享和复用,适用于多个子产品、上下游系统间的协同,模型图、模型对象参考同源、
架构配置,只有管理员可以配置,可设置模型工程视图类型,以及配置对应视图类型下面的架构图元关系和连线规则。 每种模型图是可以配置架构层级关系,下面以4+1视图下逻辑视图中的逻辑模型为例作简单说明,其它类型的模型图配置方法可参考此处,如图所示。 4+1视图中逻辑视图下的逻辑模型有自己的初始默认规则,用户可以默认使用也可自己单独配置。
创建顺序图 绘制顺序图时,必须保证图的类型为顺序图,否则可能导致无法绘制对应消息线。 已创建的模型图修改图类型具体请参考如何查看和修改模型图类型。 单击新增图。 弹出新建图弹窗选择“UML>顺序图”,填写顺序图基本信息。 父主题: 顺序图
应用场景 多种模型设计 应用:软件设计开发。 场景特点:软件设计和开发过程会有不同的角色参与其中,统一设计建模语言减少沟通成本。 适用场景:支持4+1视图和UML模型在线设计,为用户提供可视化建模语言。 模型协同设计 应用:项目协同设计。 场景特点:工程庞大、周期短的情况,需要投入多人同时开发建模。
架构信息树页签中可展示基于各种模型的架构方案规则,根据该类模型的元素关系集合生成一棵全量关系结构树。 架构方案规则的配置只有工程的管理员级别角色(带有配置资源操作权限的角色)才可配置,一般是产品的架构师来配置,制定产品的各模型中元素关系约束规则,例如逻辑模型的默认架构方案规则,方案中约
概述 4+1视图是一组相关联模型的集合,从不同的视角,反映不同利益干系人的关注点。通过逻辑、开发、部署、运行4个典型视角描述系统的各个切面,以用例串接和验证各切面设计。 在架构设计说明书模板中的4+1架构视图模型结构如下图所示: 图1 4+1架构视图模型结构图 表1 视图类型与描述
根据建模规范限制,建模的连线不能独立存在于图中,两端必须是连接在元素上的,因此不允许消息线直接拖拽至画布上。且绘制顺序图时,必须保证图的类型为顺序图,否则可能导致无法绘制对应消息线。具体请参见如何查看和修改模型图类型。 消息线介绍 顺序图用消息线描绘元素之间的工作流或者活动。软件模型中,消息线
软件建模(CodeArts Modeling)是一款集可视化、协同、规范、复用于一体的在线架构设计建模服务,不仅可以帮助用户运用UML标准的模型图来设计系统架构,还可以实现多人实时编辑和多浏览器实时同步渲染,提高研发对系统的设计效率和团队的协同效果。
权限管理 CodeArts Modeling中默认的用户角色类型及对建模的操作权限说明如下: “默认角色权限矩阵” 资源权限 项目经理 测试经理 运维经理 开发人员 测试人员 参与者 浏览者 查看(可打开模型图,只读) √ √ √ √ √ √ √ 创建(可在任何包下新增包、图、元素)
架构基础信息检查 1.1元素名称不能为空 详细描述 建模设计的元素名称不能为空,如果存在名称为空的元素,在检查结果中都会列出。 检查范围 在图上创建的元素在工程树中出现对应的节点,即为建模元素,都在被检查范围内。 如何检查 查询模型工程内所有建模元素,检查出名称为空元素。 正确示例 错误示例
依赖,是一种使用的关系,即一个类的实现需要另一个类的协助。 Association 关联,是一种拥有的关系,它使一个类知道另一个类的属性和方法。 对象图示例,如下图所示: 示例首先显示简单的类图上连接的两个类元素。 上面的类被实例化作为下面对象图中的对象。在此模型中有的两个实例计
架构检查方案功能是基于架构检查中的规则项,设置一个检查规则集合,可将该检查集合设置为架构检查中默认启用的检查规则集,该检查会生成检查任务到架构检查历史中。 单击“新增架构检查方案”,输入方案名称,规则集中的检查项来源基于通用检查规则,选择要配置到规则集中的方案。 新建名称为逻辑模型检查项,勾选对应检查规则。
四个视图的设计,用例视图不增加设计元素,仅增加用例作为输入,因此作为+1视图。 模型类别 描述 上下文模型(必选) 上下文模型描述系统和外部环境(包括人、系统及外部实体)之间的关系,依赖和交互。通过上下文模型可以显示定义系统的范围、职责、边界。 用例模型(必选) 用例模型描述系统
逻辑视图面向系统逻辑分析和设计,描述系统逻辑结构的视图,主要解决系统分析和设计的问题,它描述系统的业务上下文、系统的逻辑分解,以及分解出的逻辑元素间的关系。 模型类别 描述 逻辑模型(必选) 逻辑模型描述系统的逻辑功能模块分解,将系统分解为相应的逻辑功能元素,并描述各逻辑功能元素之间的关系。 数据模型(强数据场景必选)
构建结构的视图,主要解决系统技术实现和开发的问题,它依托逻辑视图,描述代码、构建结构。 模型类别 描述 代码模型(必选) 代码模型定义代码结构以及代码元素逻辑模型中逻辑元素的对应关系,建立逻辑元素到代码仓或者代码目录的映射关系,以实现软件源代码的显示管理。 构建模型(必选) 构