本章使用一个简单的例子对UML中所使用的概念和视图进行初览。本章的目的是要将高层UML概念组织成一系列较小的视图和图表来可视化说明这些概念,说明如何用各种不同的概念来描述一个系统以及如何将各种视图组织在一起。概括性的说明不可能面面俱到,其中省略了许多概念。要想得到更详细的说明,可参见下一章对UML各视图的说明和本书大全部分的有关细节。
本章使用的例子是计算机管理的戏院售票系统。这是一个精心设计的例子,目的是用少量篇幅来强调说明UML的各个组件。这是一个经过有意简化的例子,忽略了有关细节。除非进行大量的反复说明,否则一个实际系统的完整模型不可能用这么少的篇幅来对UML中使用的每种组件进行介绍。
1.1 UML视图
UML中的各种组件和概念之间没有明显的划分界限,但为方便起见,我们用视图来划分这些概念和组件。视图只是表达系统某一方面特征的UML建模组件的子集。视图的划分带有一定的随意性,但我们希望这种看法仅仅是直觉上的。在每一类视图中使用一种或两种特定的图来可视化地表示视图中的各种概念。
在最上一层,视图被划分成三个视图域:结构分类、动态行为和模型管理。
结构分类描述了系统中的结构成员及其相互关系。类元包括类、用例、构件和节点。类元为研究系统动态行为奠定了基础。类元视图包括静态视图、用例视图和实现视图。
动态行为描述了系统随时间变化的行为。行为用从静态视图中抽取的瞬间值的变化来描述。动态行为视图包括状态机视图、活动视图和交互视图。
模型管理说明了模型的分层组织结构。包是模型的基本组织单元。特殊的包还包括模型和子系统。模型管理视图跨越了其他视图并根据系统开发和配置组织这些视图。
UML还包括多种具有扩展能力的组件,这些扩展能力有限但很有用。这些组件包括约束、构造型和标记值,它们适用于所有的视图元素。
表 3–1列出了UML的视图和视图所包括的图以及与每种图有关的主要概念。不能把这张表看成是一套死板的规则,应将其视为对UML常规使用方法的指导,因为UML允许使用混合视图。
主要的域 |
视图 |
图 |
主要概念 |
结构
|
静态视图 |
类图 |
类、关联、泛化、依赖关系、实现、接口 |
用例视图 |
用例图 |
用例、参与者、关联、扩展、包括、用例泛化 |
|
实现视图 |
构件图 |
构件、接口、依赖关系、实现 |
|
部署视图 |
部署图 |
节点、构件、依赖关系、位置 |
|
动态 |
状态机视图 |
状态机图 |
状态、事件、转换、动作、 |
|
活动视图 |
活动图 |
状态、活动、完成转换、分叉、结合 |
|
交互视图 |
顺序图 |
交互、对象、消息、激活 |
|
|
协作图 |
协作、交互、协作角色、消息 |
模型管理 |
模型管理视图 |
类图 |
报、子系统、模型 |
可扩展性 |
所有 |
所有 |
约束、构造型、标记值 |
2.1 静态视图
静态视图对应用领域中的概念以及与系统实现有关的内部概念建模。这种视图之所以被称之为是静态的是因为它不描述与时间有关的系统行为,此种行为在其他视图中进行描述。静态视图主要是由类及类间相互关系构成,这些相互关系包括:关联、泛化和各种依赖关系,如使用和实现关系。一个类是应用领域或应用解决方案中概念的描述。类图是以类为中心来组织的,类图中的其他元素或属于某个类或与类相关联。静态视图用类图来实现,正因为它以类为中心,所以称其为类图。
在类图中类用矩形框来表示,它的属性和操作分别列在分格中。如不需要表达详细信息时,分格可以省略。一个类可能出现在好几个图中。同一个类的属性和操作只在一种图中列出,在其他图中可省略。
关系用类框之间的连线来表示,不同的关系用连线上和连线端头处的修饰符来区别。
图 3–1是售票系统的类图,它只是售票系统领域模型的一部分。图中表示了几个重要的类,如Customer、Reservation、Ticket和Performance。顾客可多次订票,但每一次订票只能由一个顾客来执行。有两种订票方式:个人票或套票;前者只是一张票,后者包括多张票。每一张票不是个人票就是套票中的一张,但是不能又是个人票又是套票中的一张。每场演出都有多张票可供预定,每张票对应一个唯一的座位号。每次演出用剧目名、日期和时间来标识。
3.3 用例视图
用例视图是被称为参与者的外部用户所能观察到的系统功能的模型图。用例是系统中的一个功能单元,可以被描述为参与者与系统之间的一次交互作用。用例模型的用途是列出系统中的用例和参与者,并显示哪个参与者参与了哪个用例的执行。
图 3–2是售票系统的用例图。参与者包括售票员、监督员和公用电话亭。公用电话亭是另一个系统,它接受顾客的订票请求。在售票处的应用模型中,顾客不是参与者,因为顾客不直接与售票处打交道。用例包括通过公用电话亭或售票员购票,购预约票(只能通过售票员),售票监督(应监督员的要求)。购票和预约票包括一个共同的部分—即通过信用卡来付钱(对售票系统的完整描述还要包括其他一些用例,例如换票和验票等)。
用例也可以有不同的层次。用例可以用其他更简单的用例进行说明。在交互视图中,用例做为交互图中的一次协作来实现。
3.4 交互视图
交互视图描述了执行系统功能的各个角色之间相互传递消息的顺序关系。类元是对在系统内交互关系中起特定作用的一个对象的描述,这使它区别于同类的其他对象。交互视图显示了跨越多个对象的系统控制流程。交互视图可用两种图来表示:顺序图和协作图,它们各有不同的侧重点。
3.4.1 顺序图
顺序图表示了对象之间传送消息的时间顺序。每一个类元角色用一条生命线来表示—即用垂直线代表整个交互过程中对象的生命期。生命线之间的箭头连线代表消息。顺序图可以用来进行一个场景说明—即一个事务的历史过程。
顺序图的一个用途是用来表示用例中的行为顺序。当执行一个用例行为时,顺序图中的每条消息对应了一个类操作或状态机中引起转换的触发事件。
图 3–3是描述购票这个用例的顺序图。顾客在公共电话亭与售票处通话触发了这个用例的执行。顺序图中付款这个用例包括售票处与公用电话亭和信用卡服务处的两个通信过程。这个顺序图用于系统开发初期,未包括完整的与用户之间的接口信息。例如,座位是怎样排列的;对各类座位的详细说明都还没有确定。尽管如此,交互过程中最基本的通信已经在这个用例的顺序图中表达出来了。
3.4.2 协作图
协作图对在一次交互中有意义的对象和对象间的链建模。对象和关系只有在交互的才有意义。类元角色描述了一个对象,关联角色描述了协作关系中的一个链。协作图用几何排列来表示交互作用中的各角色(如图3-4)。附在类元角色上的箭头代表消息。消息的发生顺序用消息箭头处的编号来说明。
协作图的一个用途是表示一个类操作的实现。协作图可以说明类操作中用到的参数和局部变量以及操作中的永久链。当实现一个行为时,消息编号对应了程序中嵌套调用结构和信号传递过程。
图 3–4是开发过程后期订票交互的协作图。这个图表示了订票涉及的各个对象间的交互关系。请求从公用电话亭发出,要求从所有的演出中查找某次演出的资料。返回给ticketseller对象的指针db代表了与某次演出资料的局部暂时链接,这个链接在交互过程中保持,交互结束时丢弃。售票方准备了许多演出的票;顾客在各种价位做一次选择,锁定所选座位,售票员将顾客的选择返回给公用电话亭。当顾客在座位表中做出选择后,所选座位被声明,其余座位解锁。
顺序图和协作图都可以表示各对象间的交互关系,但它们的侧重点不同。顺序图用消息的几何排列关系来表达消息的时间顺序,各角色之间的相关关系是隐含的。协作图用各个角色的几何排列图形来表示角色之间的关系,并用消息来说明这些关系。在实际中可以根据需要选用这两种图。
3.5 状态机视图
状态机视图是一个类对象所可能经历的所有历程的模型图。状态机由对象的各个状态和连接这些状态的转换组成。每个状态对一个对象在其生命期中满足某种条件的一个时间段建模。当一个事件发生时,它会触发状态间的转换,导致对象从一种状态转化到另一新的状态。与转换相关的活动执行时,转换也同时发生。状态机用状态图来表达。
图 3–5是票这一对象的状态图。初始状态是Available状态。在票开始对外出售前,一部分票是给预约者预留的。当顾客预定票,被预定的票首先处于锁定状态,此时顾客仍有是否确实要买这张票的选择权,故这张要票可能出售给顾客也可能因为顾客不要这张票而解除锁定状态。如果超过了指定的期限顾客仍未做出选择,此票被自动解除锁定状态。预约者也可以换其他演出的票,如果这样的话,最初预约票也可以对外出售。
状态图可用于描述用户接口、设备控制器和其他具有反馈的子系统。它还可用于描述在生命期中跨越多个不同性质阶段的被动对象的行为,在每一阶段该对象都有自己特殊的行为。
3.6 活动视图
活动图是状态机的一个变体,用来描述执行算法的工作流程中涉及的活动。活动状态代表了一个活动:一个工作流步骤或一个操作的执行。活动图描述了一组顺序的或并发的活动。活动视图用活动图来体现。
图 3–6 是售票处的活动图。它表示了上演一个剧目所要进行的活动(这个例子仅供参考,不必太认真地凭着看戏的经验而把问题复杂化)。箭头说明活动间的顺序依赖关系—例如,在规划进度前,首先要选择演出的剧目。加粗的横线段表示分叉和结合控制。例如,安排好整个剧目的进度后,可以进行宣传报道、购买剧本、雇用演员、准备道具、设计照明、加工戏服等,所有这些活动都可同时进行。在进行彩排之前,剧本和演员必须已经具备。
这个例说明了活动图的用途是对人类组织的现实世界中的工作流程建模。对事物建模是活动图的主要用途,但活动图也可对软件系统中的活动建模。活动图有助于理解系统高层活动的执行行为,而不涉及建立协作图所必须的消息传送细节。
用连接活动和对象流状态的关系流表示活动所需的输入输出参数
3.7 物理视图
前面介绍的视图模型按照逻辑观点对应用领域中的概念建模。物理视图对应用自身的实现结构建模,例如系统的构件组织和建立在运行节点上的配置。这类视图提供了将系统中的类映射成物理构件和节点的机制。物理视图有两种:实现视图和部署视图。
实现视图为系统的构件建模型—构件即构造应用的软件单元—还包括各构件之间的依赖关系,以便通过这些依赖关系来估计对系统构件的修改给系统可能带来的影响。
实现视图用构件图来表现。图 3–7是售票系统的构件图。图中有三个用户接口:顾客和公用电话亭之间的接口、售票员与在线订票系统之间的接口和监督员查询售票情况的接口。售票方构件顺序接受来自售票员和公用电话亭的请求;信用卡主管构件之间处理信用卡付款;还有一个存储票信息的数据库构件。构件图表示了系统中的各种构件。在个别系统的实际物理配置中,可能有某个构件的多个备份。
图中的小圆圈代表接口,即服务的连贯集。从构件到接口的实线表明该构件提供的列在接口旁的服务。从构件到接口的虚线箭头说明这个构件要求接口提供的服务。例如,购买个人票可以通过公用电话亭订购也可直接向售票员购买,但购买团体票只能通过售票员。
部署视图描述位于节点实例上的运行构件实例的安排。节点是一组运行资源,如计算机、设备或存储器。这个视图允许评估分配结果和资源分配。
部署视图用部署图来表达。图 3–8是售票系统的描述层部署图。图中表示了系统中的各构件和每个节点包含的构件。节点用立方体图形表示。
图 3–9是售票系统的实例层部署图。图中显示了各节点和它们之间的连接。这个模型中的信息是与图 3–8的描述层中的内容相互对应的。
3.8 模型管理视图
模型管理视图对模型自身组织建模。一系列由模型元素(如类、状态机和用例)构成的包组成了模型。一个包(package)可能包含其他的包,因此,整个模型实际上可看成一个根包,它间接包含了模型中的所有内容。包是操作模型内容、存取控制和配置控制的基本单元。每一个模型元素包含于包中或包含于其他模型元素中。
模型是从某一观点以一定的精确程度对系统所进行的完整描述。从不同的视角出发,对同一系统可能会建立多个模型,例如有系统分析模型和系统设计模型之分。模型是一种特殊的包。
子系统是另一种特殊的包。它代表了系统的一个部分,它有清晰的接口,这个接口可作为一个单独的构件来实现。
模型管理信息通常在类图中表达。
UML包含三种主要的扩展组件:约束、构造型和标记值。约束是用某种形式化语言或自然语言表达的语义关系的文字说明。构造型是由建模者设计的新的模型元素,但是这个模型元素的设计要建立在UML已定义的模型元素基础上。标记值是附加到任何模型元素上的命名的信息块。
这些组件提供了扩展UML模型元素语义的方法,同时不改变UML定义的元模型自身的语义。使用这些扩展组件可以组建适用于某一具体应用领域的UML用户定制版本。
图 3–11举例说明了约束、构造型,和标记值的使用。对剧目类的约束保证了剧目具有唯一的名称。图 3–11说明了两个关联的异或约束,一个对象某一时刻只能具有两个关联中的一个。用文字表达约束效果较好,但UML的概念不直接支持文字描述。
TicketdDB构件构造型表明这个是一个数据库构件,允许省略该构件的接口说明,因为这个接口是所有数据库都支持的通用接口。建模者可以增加新的构造型来表示专门的模型元素。一个构造型可以带有多个约束、标记值或者代码生成特性。如图所示,建模者可以为命名的构造型定义一个图标,作为可视化的辅助工具。尽管如此,可以使用文字形式说明。
3.10 各种视图间的关系
多个视图共存于一个模型中,它们的元素之间有很多关系,其中一些关系列在表3-2中。表中没有将各种关系列全,但它列出了从不同视角观察得到的元素间的部分主要关系。
表3-2 不同视图元素间的部分关系
元素 |
元素 |
关系 |
类 |
拥有 |
状态机 |
操作 |
交互 |
实现 |
用例 |
合作 |
实现 |
用例 |
交互实例 |
样本场景 |
构件实例 |
节点实例 |
位置 |
动作 |
操作 |
调用 |
动作 |
信号 |
发送 |
活动 |
操作 |
调用 |
消息 |
动作 |
激发 |
包 |
类 |
拥有 |
角色 |
类 |
分类 |
相关推荐
项目包含完整前后端源码和数据库文件 环境说明: 开发语言:Java 框架:ssm,mybatis JDK版本:JDK1.8 数据库:mysql 5.7 数据库工具:Navicat11 开发软件:eclipse/idea Maven包:Maven3.3 服务器:tomcat7
YOLO系列算法目标检测数据集,包含标签,可以直接训练模型和验证测试,数据集已经划分好,包含数据集配置文件data.yaml,适用yolov5,yolov8,yolov9,yolov7,yolov10,yolo11算法; 包含两种标签格:yolo格式(txt文件)和voc格式(xml文件),分别保存在两个文件夹中,文件名末尾是部分类别名称; yolo格式:<class> <x_center> <y_center> <width> <height>, 其中: <class> 是目标的类别索引(从0开始)。 <x_center> 和 <y_center> 是目标框中心点的x和y坐标,这些坐标是相对于图像宽度和高度的比例值,范围在0到1之间。 <width> 和 <height> 是目标框的宽度和高度,也是相对于图像宽度和高度的比例值; 【注】可以下拉页面,在资源详情处查看标签具体内容;
1、嵌入式物联网单片机项目开发例程,简单、方便、好用,节省开发时间。 2、代码使用IAR软件开发,当前在CC2530上运行,如果是其他型号芯片,请自行移植。 3、软件下载时,请注意接上硬件,并确认烧录器连接正常。 4、有偿指导v:wulianjishu666; 5、如果接入其他传感器,请查看账号发布的其他资料。 6、单片机与模块的接线,在代码当中均有定义,请自行对照。 7、若硬件有差异,请根据自身情况调整代码,程序仅供参考学习。 8、代码有注释说明,请耐心阅读。 9、例程具有一定专业性,非专业人士请谨慎操作。
手语图像分类数据集【已标注,约2,500张数据】 分类个数【36】:0、1、a、b等【具体查看json文件】 划分了训练集、测试集。存放各自的同一类数据图片。如果想可视化数据集,可以运行资源中的show脚本。 CNN分类网络改进:https://blog.csdn.net/qq_44886601/category_12858320.html 【更多图像分类、图像分割(医学)、目标检测(yolo)的项目以及相应网络的改进,可以参考本人主页:https://blog.csdn.net/qq_44886601/category_12803200.html】
CNCAP 2024打分表
系统可以提供信息显示和相应服务,其管理智慧校园管理系统信息,查看智慧校园管理系统信息,管理智慧校园管理系统。 项目包含完整前后端源码和数据库文件 环境说明: 开发语言:Java JDK版本:JDK1.8 数据库:mysql 5.7 数据库工具:Navicat11 开发软件:eclipse/idea Maven包:Maven3.3 部署容器:tomcat7 小程序开发工具:hbuildx/微信开发者工具
Matlab领域上传的视频均有对应的完整代码,皆可运行,亲测可用,适合小白; 1、代码压缩包内容 主函数:main.m; 调用函数:其他m文件;无需运行 运行结果效果图; 2、代码运行版本 Matlab 2019b;若运行有误,根据提示修改;若不会,私信博主; 3、运行操作步骤 步骤一:将所有文件放到Matlab的当前文件夹中; 步骤二:双击打开main.m文件; 步骤三:点击运行,等程序运行完得到结果; 4、仿真咨询 如需其他服务,可私信博主; 4.1 博客或资源的完整代码提供 4.2 期刊或参考文献复现 4.3 Matlab程序定制 4.4 科研合作
影音互动科普网站功能描述 影音互动科普网站旨在通过多媒体形式(视频、音频、互动内容等)传播科学知识,提高公众的科学素养。该网站结合娱乐与教育,提供易于理解的科普内容,吸引不同年龄层次的用户参与和学习。以下是该网站的主要功能描述: 1. 用户注册与登录 用户注册:用户可以通过电子邮箱、手机号或社交账号(如微信、微博等)注册,提供基本信息并设置密码。 用户登录:支持通过注册的账号登录,保障个人信息的安全性,并提供自动登录功能。 2. 科普视频与音频库 视频内容:网站提供各类科普视频,包括短视频、纪录片、讲座、实验演示等,覆盖物理、化学、生物、地理、天文等多个领域。 音频内容:提供科普音频节目,如科普广播、播客、专题讲座等,便于用户在日常生活中进行学习。 视频分类:按科目、难度、年龄层、时长等维度对视频和音频进行分类,帮助用户更精准地找到感兴趣的内容。 字幕与多语言支持:提供字幕、翻译和多语种版本,帮助不同语言的用户学习。 3. 互动问答与讨论区 专家问答:用户可以向科普专家提问,专家提供详尽的解答,解决用户的科学疑惑。 社区讨论:用户可以在视频下方或专题页面中发表评论、提问或与其他用户
倪海厦讲义及笔记,易学数据测算
内容概要:本文档是《组合数学答案-网络流传版.pdf》的内容,主要包含了排列组合的基础知识以及一些经典的组合数学题目。这些题目涵盖了从排列数计算、二项式定理的应用到容斥原理的实际应用等方面。通过对这些题目的解析,帮助读者加深对组合数学概念和技巧的理解。 适用人群:适合初学者和有一定基础的学习者。 使用场景及目标:可以在学习组合数学课程时作为练习题参考,也可以在复习考试或准备竞赛时使用,目的是提高解决组合数学问题的能力。 其他说明:文档中的题目覆盖了组合数学的基本知识点,适合逐步深入学习。每个题目都有详细的解答步骤,有助于读者掌握解题思路和方法。
内容概要:本文是一篇完整的管理系统开发指南,详细介绍了功能要求、技术栈选择、数据库设计、用户界面搭建以及安全控制等方面的内容。功能要求包括用户管理、权限控制、数据管理、系统日志、通知与消息、统计分析和扩展模块。使用的技术栈涵盖了后端(Java、Python、C#等)和前端(React、Vue.js、Angular等)技术,以及数据库设计和安全控制措施。 适合人群:具备一定开发经验的软件工程师和技术管理人员。 使用场景及目标:适用于企业级管理系统开发项目,旨在构建一个高效、安全且易于扩展的系统。开发者可以参考本文档进行系统的设计和实现,确保系统满足业务需求。 其他说明:本文档提供了详细的步骤和最佳实践,帮助开发者更好地理解和应用管理系统开发的各种技术。通过结合实际案例和实践经验,本文档能够为开发者提供有价值的指导。
听器听力损伤程度分级表.docx
MATLAB代码:基于条件风险价值的合作型Stackerlberg博弈微网动态定价与优化调度 关键词:微网优化调度 条件风险价值 合作博弈 纳什谈判 参考文档:《A cooperative Stackelberg game based energy management considering price discrimination and risk assessment》完美复现 仿真平台:MATLAB yalmip+cplex+mosek 主要内容:代码主要做的是一个基于合作型Stackerlberg博弈的考虑差别定价和风险管理的微网动态定价与调度策略,提出了一个双层能源管理框架,实现多个微网间的P2P能源交易,上层为零商的动态定价模型,目标是社会福利最大化;下层是多个产消者的合作博弈模型,优化各产消者的能量管理策略。 同时,采用纳什谈判法对多个产消者的合作剩余进行公平分配,还考虑了运行风险,采用条件风险价值(CVaR)随机规划方法来描述零商的预期损失。 求解方面,双层模型被基于KKT条件转为单层模型,模型可以高效求解。 这段代码是一个基于合作型Stackelberg博弈的微网
YOLO系列算法目标检测数据集,包含标签,可以直接训练模型和验证测试,数据集已经划分好,包含数据集配置文件data.yaml,适用yolov5,yolov8,yolov9,yolov7,yolov10,yolo11算法; 包含两种标签格:yolo格式(txt文件)和voc格式(xml文件),分别保存在两个文件夹中,文件名末尾是部分类别名称; yolo格式:<class> <x_center> <y_center> <width> <height>, 其中: <class> 是目标的类别索引(从0开始)。 <x_center> 和 <y_center> 是目标框中心点的x和y坐标,这些坐标是相对于图像宽度和高度的比例值,范围在0到1之间。 <width> 和 <height> 是目标框的宽度和高度,也是相对于图像宽度和高度的比例值; 【注】可以下拉页面,在资源详情处查看标签具体内容;
20块钱买的【动漫网页设计】源码,免费分享出来啦,如果要积分那是系统自动涨的啦。 内容概要:本资源是一份动漫网页设计的源码,价格仅为20元,作者将其免费分享给大家。该源码包含了动漫元素的设计,包括背景、图标、按钮等,同时也提供了一些常见的网页布局和交互效果。通过该资源,可以学习到动漫网页设计的基本原理和技巧。 适用人群:本资源适用于对动漫网页设计感兴趣的人群,包括网页设计师、UI设计师、前端开发工程师等。同时,对于想要学习动漫网页设计的初学者也非常适用。 使用场景及目标:该资源可以用于学习和实践动漫网页设计的技巧和原理。通过学习该源码,可以了解到动漫网页设计的基本要素和设计思路,同时也可以借鉴其中的设计元素和交互效果,应用到自己的网页设计中。 其他说明:本资源是作者自己设计的,经过了多次修改和优化,具有一定的参考价值。同时,作者也将其价格设置的非常低,希望更多的人可以学习到动漫网页设计的技巧和方法。如果您对该资源有任何疑问或建议,欢迎在评论区留言,作者会尽快回复。。内容来源于网络分享,如有侵权请联系我删除。另外如果没有积分的同学需要下载,请私信我。
自考 本科 C++程序设计-课本 参考答案
每周质量安全排查报告.docx
YOLO算法-杂草检测项目数据集-3970张图像带标签-杂草.zip
内存搜索工具(易).rar
AI大模型研究相关报告