软件建模技术 课件全套 任务1-12 初识软件建模 -集团人力资源管理系统建模设计

任务1

初识软件建模内容导图理解软件建模的基本概念。理解软件工程的基本概念。掌握UML的基本概念。掌握UML的基本组成。认识软件建模的工具。掌握建模工具的使用。能够理解软件建模的相关概念。能够理解软件工程与软件建模的关系。能够掌握UML的基本概念与组成元素。能够安装及配置软件建模工具。能够使用建模工具对软件进行建模。培养严谨的逻辑思维和系统分析能力，全面、准确地理解软件系统的需求和结构。培养持续学习的精神，不断跟进软件建模领域的新技术和新方法，提升自身的专业素养。培养严谨细致的工作态度，在安装、配置和使用建模工具时，注重每一个细节。提升解决问题的综合能力，面对安装建模工具过程中出现的各种问题，能够灵活运用所学知识和技能，探索解决方案。

模型（Model）是对现实世界的简化，软件建模是对业务系统软件进行抽象描述，通常在软件设计与分析中使用UML语言来建模。UML是一种可视化的建模语言，它可以用来创建各种不同类型的模型。

随着信息技术的飞速发展，教育领域也在不断进行数字化变革。传统的校园管理方式面临着效率低下、信息不畅通、资源整合困难、安全管理存在隐患等问题。为了提升校园管理水平，优化校园资源配置，提高师生的学习和工作体验，学院决定开发智慧校园系统。请运用本节所学知识，完成如下任务：

1.理解UML作为一种标准化建模语言在智慧校园系统设计与分析中的优势和价值；

2.掌握UML的基本组成部分，包括各种视图、图和模型元素，能够运用UML对智慧校园系统进行初步的建模和分析，读懂简单的用例图、类图等UML图例，以理解系统的功能结构和对象关系。软件建模概述01什么是模型模型是对现实的简化。它是现实事物的一种微缩表示、是一种用于生产某事物的模式，也可以是一种设计或类型，还可以是一个待模仿或仿真的样例。一个好的模型应包括那些有广泛影响的主要元素，忽略那些与抽象水平不相关的次要元素。如在对房屋进行建模中应包括房屋材料、构造结构等主要元素，忽略那些房屋中应摆放什么样的家具等次要元素。建模的目的与原则目的：①模型帮助我们按照实际情况对系统进行可视化。②模型允许我们详细说明系统。③模型给出了一个指导我们构造系统的模板。④模型对我们做出的决策进行模板化。原则：①要仔细的选择模型。②每一种模型可以在不同的精度级别上表示所要开发的系统。③模型要与实际相联系。虽然模型对现实进行了简化，但不能简化掉任何重要细节，也不能改变或歪曲任何重要细节。④对一个重要的系统用一组几乎独立的模型去处理。UML建模在音乐领域，有五线谱，供作曲家和演奏家交流。在数学领域，有各种各样的数学公式和表示方法，供数学家、教师、学生交流学习。同样，在工程领域，也有一种可以提供给工程设计人员使用的公共语言：UML。UML的中文意思是统一建模语言(UnifiedModelingLanguage)，它是一种通用的可视化建模语言。UML具有灵活，表达能力强的特点。有了建模语言，就方便我们对各种工程进行描述、分析和交流。软件工程概述02软件的基本概念软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合。其中，程序是按照事先设计的功能和性能要求执行的指令序列，数据是使得程序能够适当地操作信息的数据结构，文档是描述程序的开发、操作和维护的文字或图形资料。软件的特征：①软件是被设计开发的，而不是被制造的②软件不会“磨损”，但会“退化”③软件的开发至今尚未摆脱手工艺的开发方式④软件是复杂的软件的划分系统软件

指能与计算机硬件紧密结合在一起，使计算机系统各个部件、相关软件和数据协调高效地工作的软件。如操作系统软件、数据库管理软件、通信处理软件等。支撑软件是指协助用户开发软件的工具性软件，包括帮助程序员开发软件产品的工具，也包括帮助管理人员控制开发的进程的工具。如Java开发工具Eclipse等。应用软件是指在特定领域内开发，为特定目的服务的一类软件。应用软件的种类非常繁多，如计算机辅助设计制造软件、系统仿真软件、人工智能软件、办公自动化软件、计算机辅助教学软件等。软件危机早期的程序开发者只是为了满足自己的需要，这种自给自足的生产方式是软件开发低阶段的表现。随着计算机硬件技术的进步，生产硬件的成本降低了，这使得对软件有了更好的高要求，所以，出现了一些复杂大型的软件项目。但是，软件技术的发展落后于软件复杂的需求，随着问题的日积月累，在20世纪六七十年代逐渐形成了所谓的软件危机。软件开发中出现的问题归结如下：①软件开发无计划性，进度的执行和实际情况有很大差距。②软件需求分析阶段工作做得不充分，前期问题不及时解决，造成后期矛盾的集中暴露。③软件开发过程中没有统一的规范指导，参与软件开发的人员各行其事。④软件产品无评测手段。软件工程使用工程化的理论和方法组织软件开发工作能有效的解决这些问题，也是摆脱软件危机的一个主要出路。这就引出了软件工程的概念。软件工程是指：将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件开发。软件的三个阶段定义阶段该阶段关注于“做什么”。软件开发人员在该阶段需要弄清楚要处理什么信息，完成什么样的功能，达到什么样的性能，希望出现什么样的系统行为，建立什么样的界面，有什么设计约束，以及实现一个成功系统的验收标准是什么。开发阶段该阶段关注于“如何做”。软件开发人员需要进行如下工作：数据如何被结构化，功能如何被实现于软件体系结构中，界面如何表示，设计如何被翻译成程序设计语言，测试如何进行。支持阶段该阶段关注于“变化”。在已有软件的基础上，软件开发人员需要纠正软件中可能存在的错误，为适应外部环境的变化而修改软件，为扩展原来的功能需求而增强和升级软件。软件生存期①计划确定要开发软件系统的总目标。由系统分析员和客户人员合作，进行该软件项目的可行性研究，探讨解决问题的可能方案，对开发成本、开发收益、开发进度做出估计，最后制订出详细的软件开发实施计划。②需求分析和定义对客户提出的需求进行详细的分析。系统分析员和客户人员共同商讨哪些需求是可以满足的，并对其进行准确的描述，最后编写出项目需求说明书。软件生存期③软件设计（详细设计）在设计阶段，系统分析员和软件设计人员一起把已经确定了的各个需求转换成一个相应的体系结构。结构中的每一组成部分都是意义明确的模块，每个模块和某些需求相对应。该阶段的成果物是设计说明书，该说明书对每个模块进行了详细的描述。④编码软件设计人员和程序员一起将软件设计转换成程序代码。该阶段的成果物是程序清单。软件生存期⑤软件测试软件测试人员设计各种测试用例来检验软件。测试是保证软件质量的重要手段。该阶段的成果物是测试用例书、测试数据和测试结果。⑥运行和维护已交付的软件投入正式使用后，就进入维护阶段。软件在运行过程中可能由于多方面的原因，需要对它进行修改。维护的工作可能包括：在软件的运行过程中发现了错误需要修正；给软件做适当变更以适应变化了的软件工作环境。软件生存期模型软件生存期模型是从软件项目需求定义直至软件废弃为止，跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框图。软件工程方法—面向对象面向对象技术是一个非常实用而强有力的软件开发方法，和传统的软件工程方法相比较，它有许多新特色。面向对象技术导致复用，而程序构件的复用导致更快的软件开发和高质量的程序。对象：对象是面向对象开发模式的基本组成部分。对象是一种看问题的观点，是对现实世界各种真实事物的一种抽象。对象既含数据又含处理数据的功能，因此，对象被认为是迄今最接近真实事物的数据抽象。类：类是具有相同属性、相同操作的一组对象的集合的抽象描述。类的定义包括一组数据属性和在数据上的一组合法操作。类定义可以视为一个具有类似特征与共同行为的模板，用来产生对象，因此，每个对象都是类的实例。软件工程方法—面向对象继承：继承是使用已存在的定义作为基础建立新定义的技术。一个子类X继承父类Y的所有属性和操作，这意味着，所有原本针对Y设计和实现的数据结构和算法对X是立即可用的，不需要进行进一步的工作。通信：一个对象和另一个对象之间，通过消息来进行通信。消息是一个对象发出的让另一个对象做某个动作的请求。当一个对象收到发给自己的消息的时候，则调用消息中指定的操作。对消息的处理可能会改变对象的状态。可以认为，消息的传递大致等价于面向过程方法中的函数调用。软件工程过程—Rational统一过程Rational统一过程(RationalUnifiedProcessRUP)是一种软件工程过程软件工程与软件建模的关系软件工程是一门应用工程原则、方法和工具来开发和维护软件的学科。它涵盖了软件生命周期的各个阶段，包括需求分析、设计、编码、测试和维护。软件建模则是软件工程中的一个关键活动，它使用图形化的方式来表示软件系统的不同方面，帮助开发者和利益相关者更好地理解和沟通软件的结构、行为和功能。软件工程和软件建模之间的关系密切。软件工程为软件建模提供了一个系统化的方法论框架，而软件建模则为软件工程的各个阶段提供了一种直观和高效的沟通工具。通过软件建模，开发者可以在早期阶段识别和解决潜在的设计问题，减少后期修改的成本和风险。同时，软件建模也支持需求的可视化和验证，有助于确保软件满足用户的实际需求。此外，软件建模还促进了软件的可维护性和可扩展性。通过创建清晰和一致的模型，开发者可以更容易地理解和修改现有系统，为未来的维护和升级打下基础。在软件工程实践中，统一建模语言（UML）等建模技术被广泛应用于不同阶段，以支持软件的分析、设计和实现。UML概述03UML简述统一建模语言UML(UnifiedModelingLanguage)是一种通用的可视化建模语言，用于对软件系统进行描述、可视化处理、构造和建立系统的工作文档。UML体系由三个部分组成：UML基本构造块、UML规则和UML公共机制。UML构造块事物包括结构事物、行为事物、分组事物、注释事物。关系包括依赖关系、关联关系、泛化关系、实现关系。图包括类图、对象图、用例图、顺序图、协作图、状态图、活动图、组件图、部署图等常见九种。UML规则一个结构良好的模型在语义上应该是前后一致的，并且与所有的相关模型协调一致。UML通过定义一套规则来告诉我们如何使用UML构造块搭建出一个结构良好的模型。UML有用于描述如下事物的语义规则：“命名”、“范围”、“可见性”、“完整性”、“执行”等。UML公共机制在UML中有多种贯穿整个语言的公共机制，主要包括：规格说明、修饰、通用划分和扩展机制。UML的应用领域UML的目标是以面向对象的方式来描述任何类型的系统，其中最常用的是建立软件系统模型。UML的设计初衷是为了支持面向对象系统建模，以及基于构件的开发。通过使用UML内置的扩展和用户定制能力，UML同样也可以用来描述非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。总之，UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。UML适用于系统开发过程中从需求规格描述到系统完成测试后的不同阶段。例如，在需求分析阶段，可以用用例来描述客户的需求；在设计阶段，可以用UML动态模型来描述对象与对象之间的关系；在测试阶段，UML模型还可以作为测试的依据。UML基本组成04UML事务事物是对模型中最有代表性的成分的抽象。UML中有四种事物。①结构事物(structuralthing)：结构事物常指软件模型的静态部分，描述概念或物理元素。UML中的结构事物有：（1）类(class)：类是具有相同属性和操作的一组对象集合的抽象描述。在图形上，类用一个矩形来表示，通常矩形中写有类的名称、类的属性和类的操作。UML结构事务（2）组件(component）：组件是系统中物理的、可替代的部件，是用于描述一些逻辑元素(如类、接口)的物理包。在图形上，组件由一个带有小方框的矩形表示。通常在矩形中只写该组件的名字。UML结构事务（3）接口(interface)：接口是描述了类或组件的服务操作集，或者说，接口描述了类或组件对外的、可见的动作。类可以实现一个或多个接口。在图形上，接口用一个带有名称的圆表示。接口很少单独存在，而是依附于实现接口的类或组件。UML结构事务协作(collaboration)：协作是一组类、接口和其它元素的群体，它们共同工作，提供比各组成部分的功能总和更强的合作行为。与组件不同，协作不能拥有自己的结构事物，而只能引用其它地方定义的类、接口、组件、节点等结构事物，即协作是系统体系结构中的概念组块而不是物理组块。在图形上，协作用一个包含名称的虚线椭圆表示。UML结构事务用例(usecase)：用例是对一组序列动作的描述，系统执行这些动作将对用例的角色(actor，有些书翻译成“参与者”，本书以下均简称为“角色”)产生可以观察的结果。在图形上，用例用实线的椭圆表示，角色用一个人形的图案表示。举例来说，在一个图书管理系统中，考虑读者这一角色可以有什么样的动作行为。读者可以借书，也可以还书。那么我们可以用用例图的方式将这组动作描述出来。UML结构事务节点(node)：节点是一个物理元素，它在运行时存在，代表一个可计算的资源，比如说一台数据库服务器。在图形上，节点用一个立方体来表示UML行为事务②行为事物(behavioralthing)：结构事物描述的是模型的静态部分，而行为事物描述的是模型的动态部分。UML有两类主要的行为事物。（1）交互(interaction)：对象都不是孤立存在的，它们之间通过传递消息进行交互。在图形上，交互的消息通常用带箭头的直线表示。UML行为事务（2）状态机（StateMachine）：一个状态机是一个行为，它说明对象在它的生命周期中响应时间所经历的状态序列以及它们对那些事件的响应。状态是指在对象的生命周期中满足某些条件、执行某些活动或等待某些事件时的一个条件或状况。一个事件的到来，能够触发一个状态的转换。UML分组事务③分组事物(groupingthing)：分组事物是UML模型中负责分组的部分，可以把它看作一个个的盒子，每个盒子里面的对象关系复杂，而盒子与盒子之间的关系相对简单。最主要的分组事物是包。包(package)是把元素组织成组的机制。结构事物、行为事物甚至其他的分组事物都可以放进包内。包与组件的区别在于，包纯粹是一种概念上的东西，仅在开发过程中存在，而组件是一种物理的元素，存在于系统运行和维护时期。在图形上，包用一个在左上角带有一个小矩形的大矩形表示。UML分组事务④注释事物(annotationalthing)：注释事物是UML模型的解释部分。这些注释事物用来描述、说明和标注模型的任何元素。有一种主要的注释事物，称为注释(note)。在图形上，注解用一个右上角是折角的矩形表示。UML关系UML中关系(relationship)包括四种：依赖(dependency)、关联(association)、泛化(generalization)和实现(realization)。依赖是两个事物间的语义关系，其中一个事物(独立事物)发生变化，将会影响另一个事物(依赖事物)的语义。在图形上，把一个依赖关系绘成一条带箭头的虚线，还可以在其上进行标记。UML关系关联关系表明了一个事物的对象与另一个事物的对象间的关系。在图形上，关联用一条实线表示，它可能有方向，还可以在其上进行标记。UML关系泛化关系是用于表达特殊与一般的关系，是一般事物（父类）和该事物较为特殊的种类（子类）之间的关系。子类继承父类的属性和操作，除此之外，子类通常还添加新的属性和操作。在图形上，泛化用从子类指向父类的空心三角形箭头表示，多个泛化关系可以用箭头线表示的树形来表示，每个分支指向一个子类。UML关系实现关系将一种模型元素（如类）与另一种模型元素（如接口）连接起来，其中接口定义行为只是而不涉及结构或实现。也就是说，关系中的一个模型元素只具有行为的定义，而行为的具体实现，则是由另一个模型元素来给出。在两个地方要遇到实现关系：一种是在接口和实现它们的类或组件之间，另一种是在用例和实现它们的协作之间。在图形上，实现关系用一个带空心三角形箭头的虚线表示。UML图图是一组元素的图形表示。为了对系统进行可视化，可以从不同的角度画图。在理论上，图可以包含任何事物及其关系的组合。UML2.0中的图可以分为结构图和行为图两种。1.结构图（UMLStructuralDiagram）类图（ClassDiagram）：展现了一组对象、接口、协作和它们之间的关系。类图给出了系统的静态设计视图。在面向对象系统的建模中，最常建立的图就是类图。类图通常是一个矩形框，分成三行，第一行代表类名，第二行代表属性，第三行代表方法。UML结构图对象图(ObjectDiagram)：对象图展现了一组对象以及它们之间的关系。和类图类似，对象图也给出了系统的静态设计视图UML结构图包图(PackageDiagram)：包图是一种符号表示的模型元素的组合，‌用于在UML中表示相关元素的组合。‌它使用类似于文件夹的符号来表示，‌允许将模型元素如用例或类组织成组。UML结构图组件图(ComponentDiagram)：组件图展现了一组组件之间的组织和依赖。组件图专注于系统的静态实现图。它与类图是息息相关的，通常情况下，组件被映射成一个或多个类、接口或协作。UML结构图（5）部署图（DeploymentDiagram）：部署图展现了在系统运行时，进行处理的节点以及在节点上活动的组件的配置。部署图给出了体系结构的静态部署视图。UML结构图组合结构图（CompositeStructureDiagram）：组合结构图是UML2.0中新增加的一种图，用来描述系统中某一部分（即“组合结构”）的内部结构，包括该部分与系统其他部分的交互点；它能够展示该部分“内部”参与者的配置情况。UML行为图行为图（UMLBehavioralDiagram）（1）用例图（UseCaseDiagram）：用例图展示了一组用例、角色以及它们之间的关系。用例图给出了系统的静态用例视图。UML行为图（2）顺序图（SequenceDiagram）顺序图是一种强调消息时间顺序的交互图。交互图（InteractionDiagram）是指：它展现了一种交互，由一组对象和它们之间的关系组成，包括它们之间可能发送的消息。交互图是描述系统的动态视图UML行为图（3）通信图（CommunicationDiagram）：通信图又叫做协作图，也是一种交互图，它强调收发消息的对象的组织结构。因为通信图和顺序图在结构上是相同的，所以它们是可以互相转换的。UML行为图（4）状态机图（StateMachineDiagram）：状态机图展现了一个状态机，它由状态、转换、事件和活动组成。状态机图是用于描述系统的动态视图。UML行为图（5）活动图（ActivityDiagram）：活动图是一种特殊的状态机图，它展现了在系统内从一个活动到另一个活动的流程。活动图是描述系统的动态视图。它强调了对象间的控制流程，因此对系统的功能建模非常重要UML行为图（6）定时图（TimingDiagram）：定时图是UML2.0中新增加的一种图，主要用于展示系统内部或多个系统之间在时间序列上的对象状态变化及事件的互动。主要由以下几个基本组件构成：时间轴、生命线、状态、时间约束，通过这些组件的组合，定时图能够清晰地描述系统行为随时间变化的情况，特别是对并发系统和实时系统的分析和设计特别有用。UML行为图（7）交互概览图（InteractionOverviewDiagram）：交互概览图是UML2.0中新增加的一种图，用于描述业务过程中的控制流概览和软件过程中的消息逻辑概览。它是活动图和顺序图的混合物，能够将多个图进行连接，从而提供一个全面的交互概览。这种图特别适合于实时和嵌入式系统的建模，因为它强调了消息跨越不同对象或参与者的实际时间。交互概览图并没有引入新的建模元素，其主要元素来自于活动图和顺序图，因此它是一种将不同交互图衔接在一起的图建模工具Enterprise

Architect05EA简介EnterpriseArchitect（以下简称为EA）是由澳大利亚SparxSystems公司设计开发的一套软件辅助开发平台。EnterpriseArchitect是基于UML2.4标准设计开发的，具有从业务需求、到软件设计，直至部署的软件开发全过程的设计与管理能力。该平台还可以根据所创建的UML模型生成Java、C#、C++等10余种源程序代码。SparxSystems公司根据用户的不同需求发布了企业版、专业版和桌面版三种EnterpriseArchitect版本。EA建模步骤-启动启动EnterpriseArchitect9.0后，进入主界面，首先弹出对话框。在该对话框中可以创建、打开项目工程。EA建模步骤-工作界面进入EA工作界面后，该界面是由标题栏、菜单栏、工具栏、工作区和状态栏组成。EA建模步骤-创建模型使用EA创建软件模型工程有两种方法：一种是在启动EA时使用启动对话框来创建项目工程；另一种方法则是通过选择主菜单“文件”→“新建项目...”来创建。EA建模步骤-发布模型EA可以把建立好的模型以RTF文档或HTML网页格式发布，这样可以让其他即使没有安装EA软件的人员，也可以通过Word或网页浏览器（如InternetExplorer）浏览模型。EA建模步骤-设置全局属性从菜单栏选择“工具→选项”，将弹出对话框。在该对话框里可以设置一些全局属性，如字体、颜色、正向工程源代码模板设置等。初识智慧校园系统建模06软件开发人员可以使用UML图向智慧校园系统的用户清晰地展示系统的功能架构和业务流程，用户也可以基于自己对校园业务的理解，通过UML图向开发人员反馈需求和建议。智慧校园系统是一个集成化的校园管理平台，涵盖教学管理、学生管理、行政管理、后勤管理等多个方面，实现信息的集中管理和共享。因为此系统较为庞大，故本书选取了系统中的登录注册模块、充值管理模块、学生寝室保修模块、门禁模块等若干子模块进行建模分析。（1）识读用例图在智慧校园系统中，用户分为游客和注册用户，游客可以进行注册，注册用户可以进行登录、退出系统、修改个人资料、查看个人资料等业务。用户、游客、注册用户均是“角色”，注册、登录、退出系统、修改个人资料、查看个人资料是五个“用例”。（2）识读类图图1-40展示了智慧校园系统中登录、注册子模块类图中的，用户类（User）和角色类（Role），并给出了两个类之间的依赖关系，每个用户都有自己相应的角色以及角色对应的权限。（3）识读对象图如图1-41所示，以图1-40的类图为例，展示了对应类图中User类的一个学生对象，其中属性UserId的值为“2410001”，对应的角色Role类的对象，其中属性roleName的值为“学生”。（4）识读包图图1-42展示了智慧校园系统的日常生活自助服务子模块包图，并且还展示了包与包之间的关联关系。（5）识读顺序图图1-43显示了一个顺序图的例子，该图描述了在智慧校园系统中用户登录的交互过程，表示了用户对象、用户登录界面、用户登录控制对象、数据库管理对象之间发送消息的先后顺序。用户对象在用户登录界面填写登录表单，然后发送表单数据给用户登录控制对象，用户登录控制对象调用查找用户记录方法，到数据库管理对象中查找对应的用户记录，然后各对象按照顺序返回结果。（6）识读通信图图1-44显示了一个登录通信图的示例。该图描述了用户进行登录的流程，用户请求登录后，与用户登录界面对象、用户登录控制类对象以及数据库管理对象之间的相互协作。从协作图中可以看出，用户对象只与用户登录界面对象协作，用户登录界面对象还与用户登录控制类对象协作，而用户登录控制类对象还与数据库管理对象协作。（7）识读状态机图图1-45显示了智慧校园系统中登录行为的状态转换，从开始状态到等待填写表单状态，提交表单后，返回登录成功或者登录失败两种状态之一。（8）识读活动图图1-46展示了智慧校园系统中用户的登录流程。要进行登录，首先需要进入登录界面，输入登录相关信息，提交给系统。系统验证用户提交的登录信息是否正确。如果验证通过，进入系统首页；如果验证不通过，显示登录失败信息。（9）识读组件图图1-47显示了智慧校园系统中用户交互模块的组件图示例。图中包含五个组件，其中用户交互组件依赖于其余四个组件。（10）识读部署图图1-48显示了智慧校园系统的部署图。该图中包括了两个客户端，分别是客户端和管理员端，通过客户端访问系统。经过负载均衡服务器后，应用服务器提供服务给客户端。负载均衡服务器在获得从客户端发送来的请求后，向应用服务器申请处理，应用服务器接受申请后开始处理请求，并把处理结果存储在数据库服务器中，同时把结果反馈给应用服务器最终返回给客户端。（11）识读组合结构图图1-49显示了寝室组合结构图，本图标识了寝室类Dormitory。图框中显示了包含类Dormitory的两个内部组合部件，这两个部件表示一个寝室的内部组成，分别为学生类User、椅子类Chair。每当从Dormitory类创建组合结构图时，就会创建User类和Chair类的实例。这些部件归Dormitory实例中的组合所有。（12）识读定时图图1-50展示了智慧校园系统中用户刷脸开门的几种状态变化以及时间变化。（13）识读交互概览图如图1-51所示，这个交互概览图将用户登录顺序图、充值顺序图以及操作自助洗衣服务顺序图衔接在一起，形成了用户充值自助洗衣的交互概览图。在软件领域，软件建模是软件工程中的重要组成部分。随着科技的发展，软件行业也在不断进步。在软件建模的过程中，从业者在探索“什么是模型”以及明确“建模的目的和原则”时，需秉持工匠精神，以严谨细致的态度对待每一个环节。从需求分析到架构设计，再到应用，每一个步骤都需要精心雕琢，反复考量，就如同工匠打造一件精美的艺术品，不断打磨、调整，力求达到最完美的状态，以确保软件系统的质量和性能。1.软件建模概述2.软件工程概述3.UML概述4.UML基本组成5.建模工具Enterprise Architect任务2

使用用例图实现系统需求分析内容导图理解用例图的基本概念及其在系统需求分析中的作用。掌握用例图的基本组成元素。掌握用例图中元素之间的关系。掌握用例图的建模方法。能够根据用户需求绘制出符合UML规范的用例图。能够通过用例图分析产品所需的功能和动态行为。培养问题解决能力，能够运用用例图等分析工具，创造性地提出解决方案，并持续优化和完善。培养良好的沟通能力，在与用户交流的过程中，能够很好地理解用户的需求，同时也可以捕捉到用户未明确表达的潜在需求。

在智慧校园系统的需求分析阶段，使用用例图是一种非常有效的方法，因为它能够帮助我们从用户的角度出发，清晰地描述系统的功能需求。请运用本节所学知识，完成如下任务：1.定义智慧校园日常生活自助服务子模块的参与者和用例；2.解析智慧校园日常生活自助服务子模块用例图中的关系；3.绘制智慧校园日常生活自助服务模块用例图。用例图概述01需求问题与软件项目风险需求问题与软件风险需求问题导致软件项目高风险，如需求不明确、理解错误、需求不完整和变化忽视需求分析的误区忽视需求分析，开发人员急于编码，如同建筑师未设计好就想添砖加瓦需求的重要性需求是客户满意度的关键，明确了需求，才能确保开发的系统符合客户期望，避免反复修改造成的资源浪费UML需求建模与用例图用例图是显示一组用例、参与者以及它们之间关系的图。用例图从用户的角度而不是开发者的角度来描述对软件产品的需求，分析产品所需的功能和动态行为。用例图常用来对需求建模。学生寝室报修子模块用例图通过学生寝室报修子模块用例图我们可以了解到，该模块包含学生、工作人员和系统管理员三个角色，其中后勤人员和行政人员都属于工作人员角色。每个角色具体的功能为：学生可以删除、新增、修改、提交维修工单，也能查询维修单进度；后勤人员可以接收和处理维修单；行政人员可以派发和查询维修单；系统管理员可以维护基础信息。用例图的组成元素02参与者参与者（Actor，有些书翻译成“角色”）

是一种特殊的类，是系统外部的一个实体，这个实体可以是任何的人或物，它以某种方式参与了用例的执行过程。参与者图标参与者在获取用例前首先要确定系统的参与者，可以根据下面的一些问题来寻找系统的角色。①谁使用系统？②谁安装系统、维护系统？③谁启动系统、关闭系统？④谁从系统中获取信息，谁提供信息给系统？⑤在系统交互中，谁扮演了什么角色？⑥系统会与哪些其他系统相关联？学生寝室报修子模块参与者【示例2-1】某商业公司为提高货物管理效率，决定开发一套货物管理的软件系统，

该系统主要功能辅助销售员、仓库管理员完成商品仓储与销售方面的工作。请你根据该系统功能要求找出该系统的角色。用例用例是对一组序列动作的描述，系统执行这些动作将对用例的角色产生可以观察的结果。用例定义了系统是如何被参与者使用的，其最大的优点是站在用户的角度描述系统的功能。用例的目的是确保系统能够满足用户的需求，并且在设计和开发过程中提供明确的指导。用例图标识别用例我们如何从系统需求分析中提取出用例？可以根据下面的一些问题来识别用例：①角色希望系统提供什么功能；②系统是否存储和检索信息；③当系统改变状态时，是否通知角色；④是否存在影响系统的外部事件，是哪个角色通知系统这些外部事件。学生寝室报修子模块用例【示例2-2】

请根据【示例2-1】

所描述的货物管理系统功能找出系统的用例。用例的粒度用例的粒度是指用例描述的详细程度。在软件工程中，用例粒度的选择取决于项目的规模、复杂性以及用例的目的。大粒度用例和小粒度用例系统边界系统边界指系统与系统之间的界限，它用于区分系统内部和外部的实体及其交互。系统边界明确了系统的范围，帮助开发者理解哪些元素是系统的一部分，哪些元素是外部环境。系统边界通常用一条实线框来表示。系统边界用例图中的关系03参与者之间的关系—泛化关系泛化关系（也称继承关系）

描述了一个参与者角色如何继承另一个参与者角色的特性和行为。在用例图中，用带空心三角形的实线来表示，从子角色指向父角色。参与者之间的泛化关系协作关系通常在用例图的详细设计阶段中体现，描述了不同参与者在完成特定功能时的互动模式。在用例详细说明中表示时，一般是描述多个参与者如何一起完成某一任务。参与者之间的关系—协作关系参与者与用例的关系—关联关联（Association）

用于表示参与者和用例之间的对应关系。关联表示参与者使用了系统中的哪些服务

（用例），或者说系统所提供的服务

（用例）

是被哪些参与者所使用的。用例图中的关联关系使用带箭头的实线表示。参与者与用例的关联关系用例之间的关系—泛化关系当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。泛化关系在图形上使用带空心箭头的实线表示，箭头由子用例指向父用例。用例泛化关系用例之间的关系—包含关系包含是指基础用例

（BaseUseCase）

会用到被包含用例

（InclusionUseCase）。被包含用例是可重用的用例──多个用例的公共用例。包含关系在图形上使用带箭头的虚线表示，箭头由基础用例指向包含用例。用例包含关系用例之间的关系—扩展关系扩展关系是指将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。选用扩展关系可以降低基础用例的复杂性。扩展关系在图形上也是使用带箭头的虚线表示，箭头由扩展用例指向基础用例。用例的扩展关系【示例2-3】

根据

【示例2-2】

中识别出的用例与角色，分析出用例之间的关系，并绘制用例图。用例描述04用例与事件流用例描述的是角色与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来。针对每一个用例我们可以用事件流来描述这一对话的细节内容。用例的各种场景中，最常见的场景是用基本流（BasicFlow）来描述的，其他的场景则是用备选流（AlternativeFlow）来描述。通过基本流与备选流的组合，就可以将用例所有可能发生的各种场景全部描述清楚。用例描述的基本结构一个完整的用例描述通常包括以下几个部分：用例名称：简明扼要地描述用例的主要功能或目的。

参与者：列出与用例交互的所有外部实体，包括主要参与者和次要参与者。

前置条件：描述用例开始执行之前必须满足的条件。

基本事件流：详细描述用例的主要流程，包括参与者和系统之间的交互步骤。备选事件流：也称扩展事件流，描述在主事件流中可能出现的异常情况或分支流程。后置条件：用例执行完毕后系统应达到的状态。

特殊需求：列出实现用例所需满足的任何特定需求，如性能、安全等。用例描述的基本结构基于智慧校园在线图书馆子模块中的“查找书籍”用例的用例描述：内

容说

明用例编号001用例名称查找书籍用例说明根据用户的输入呈现查询书籍的结果参与者学生、教师前置条件用户已登录智慧校园系统后置条件用户能够查看到所需书籍的详细信息，系统记录用户的搜索历史

基本事件流1.

用户在搜索框输入书籍相关信息（如书名、作者、ISBN等）2.

系统在数据库中搜索匹配的书籍3.

系统返回搜索结果列表4.

用户从列表中选择需要的书籍5.

系统显示所选书籍的详细信息扩展事件流1a.如果没有找到匹配的书籍，系统显示“未找到书籍”的消息1b.用户可以选择修改搜索条件或重新输入搜索信息特殊需求系统应能在1秒内响应用户的搜索请求，并在搜索结果中提供至少10本相关书籍用例图的建模技术05用例图的建模技术——对系统语境建模1.识别系统边界确定系统边界，内部功能以矩形框表示，框内包含系统提供的用例3.组织参与者如果有需要，可以使用泛化关系来组织具有相同特征的参与者，这有助于我们理解不同参与者之间的关系。2.识别参与者参与者是与系统交互的外部实体，可以是人、外部系统或其他事物。4.描述通信路径将参与者应用到用例图中，并描述参与者与用例间的通信路径，即参与者如何与系统的功能进行交互。用例图的建模技术——对系统需求建模识别参与者：

与系统语境建模类似，首先需要识别出所有与系统交互的参与者。考虑参与者的期望：对于每个参与者，考虑他们期望系统提供的行为或与系统的交互。提炼行为成用例:将参与者期望的行为提炼成用例。完善其他用例：

：分解用例中的公共行为和扩展行为，放入新的用例中以供其他用例使用。创建用例图：创建用例图：将所有识别的用例与参与者绘入，用线条表示它们之间的包含、扩展等关系。添加注解或约束:用例图中的注解或约束可说明系统非功能需求，如性能、安全标准，助于理解系统交互和功能。用例图的建模技术1.识别系统边界确定系统边界，内部功能以矩形框表示，框内包含系统提供的用例3.组织参与者如果有需要，可以使用泛化关系来组织具有相同特征的参与者，这有助于我们理解不同参与者之间的关系。2.识别参与者参与者是与系统交互的外部实体，可以是人、外部系统或其他事物。4.描述通信路径将参与者应用到用例图中，并描述参与者与用例间的通信路径，即参与者如何与系统的功能进行交互。对系统需求建模

智慧校园系统日常生活自助服务子模块的主要功能是为用户提供自助服务，包括洗衣机自助服务和热水自助服务，同时提供在线支付和查询消费记录功能。管理人员负责维护自助设备和统计设备使用率。在绘制智慧校园日常生活自助服务子模块用例图时，我们首先需要识别出该子模块的主要参与者和用例，然后再确定用例图中存在的关系。（1）确定系统角色（2）定义用例（3）分析用例图中存在的关系1.创建用例图2.创建参与者“用户”3.创建用例4.创建“用户”角色与用例之间的关联5.创建用例之间的关系6.根据任务分析结果，重复步骤2-5（1）创建用例图（3）创建用例（4）创建“用户”角色与用例之间的关联（5）创建用例之间的关系日常生活自助服务子模块用例图（6）根据任务分析结果，重复步骤（2）

-（5），创建“管理人员”角色对应的用例及关系用例图不仅仅只是一种单纯的图例功能显示，它还是开发者与用户之间进行有效沟通以及深度思考的重要桥梁。在我们日常的学习和生活当中，应当有意识地锻炼自己的沟通能力，这样才能够准确捕捉到用户的真实需求，这也是构筑高效、实用系统设计的重要基石。同时，在用例图的分析过程中，我们还需要有挖掘用户潜在需求的能力，这就要求我们不仅要悉心聆听用户的表述，更要深入分析用户反馈的信息，以此洞察并领悟他们的真实意愿与期望。通过不断提升这一能力，我们才能够创建出更加贴合用户期待的系统，从而为用户带来更加出色的使用体验。1.用例图2.用例图的组成元素3.用例图中的关系4.用例描述任务3

使用活动图实现业务分析内容导图理解活动图的基本概念及在业务分析中的作用。掌握活动图的基本组成元素。掌握活动图的建模方法。能够根据实际业务需求绘制符合UML规范的活动图。能够利用活动图对业务流程进行优化和重构。通过分析复杂的业务流程，培养学生良好的逻辑思维和系统思维能力。通过绘制和分析活动图，培养学生从全局视角审视业务流程的能力。

活动图是UML中描述系统动态行为的动态图的一种，用于展现参与行为的类的活动或动作。一张活动图从本质上说是一个流程图，它显示了系统中从一个活动到另一个活动的流程。使用活动图来描述用例的活动，有助于对系统的业务建模。在智慧校园系统的需求分析阶段，活动图可以用来描述日常生活自助服务子模块的充值业务流程。请运用本节所学知识，完成如下任务：1.分析智慧校园系统用户充值业务流程2.绘制智慧校园系统用户充值活动图活动图概述01UML需求建模与用例图活动图在本质上类似于传统的流程图，但其具有更强的表达能力，能够描述并发、分支、合并等复杂流程。活动图着重表现系统行为，描述对象活动的顺序关系所遵循的原则。活动图提供了一种描述业务流程的方法，它可以用来描述在何处、何时、发生何种动作。自助洗衣服务图例活动图通过自助洗衣服务图例活动图我们可以了解到，自助洗衣服务是由用户、系统和洗衣机三方协作完成，以及其具体业务流程。活动图的组成元素02动作状态对象的动作状态（Action）

是活动图中最小单位的构造块，表示原子动作。动作状态可以有入转移，入转移既可以是动作流，也可以是对象流。动作状态至少有一条出转移，这条转移以内部的完成为起点，

与外部事件无关。在UML中，动作状态使用圆角矩形表示，动作状态所表达的动作写在方框的内部。动作状态图标活动状态动作状态表示的是不可分割的原子动作，而活动状态

（Activity）表示的是可以分割的动作。如果某活动状态是只包括一个动作的活动状态，那它就是动作状态，因此动作状态是活动状态的一个特例。在UML中，动作状态和活动状态的图标没有区别，都是带圆角的方框。活动状态图标开始节点和终止节点在活动图中用开始节点（InitialNode）

和终止节点（FinalNode）

表示活动的开始和结束。开始节点表示一个工作流程的开始，用实心圆点来表示。在一个活动图中只有一个起始状态。终止节点表示一个活动图的最后和终结状态，一个活动图中可以有0个或多个终止节点，终

止节点用实心圆点外加一个小圆圈来表示。开始节点和终止节点转移转移

（Transition）

是两个状态间的一种关系，表示对象将在当前状态中执行动作，并在某个特定事件发生或某个特定的条件满足时进入后继状态。转移显示了从一个动作或活动状态到下一个动作或活动状态的路径。拔打电话的活动图合并和分支活动图的分支（Branch）用于描述基于某个条件的可选择路径。合并（Merge）指的是两个或者多个控制路径在此汇合的情况。在UML活动图中，分支与合并都是用空心的菱形表示的。带分支和合并的活动图【示例3-1】为在线选课系统中课程管理模块的添加课程用例绘制相应的活动图。

分析：在课程管理模块中，要对课程进行添加操作，首先需要输入课程信息，在数据库中进行查找是否已经存在该课程。如果课程不存在，则将课程信息保存到数据库中，并提示课程添加成功；如果课程已存在，则提示用户课程已存在，无法添加。典型案例【示例3-1】【示例3-2】为在线选课系统中课程管理模块的修改课程用例绘制相应的活动图。

分析：修改课程用例从“用户”泳道开始“输入要修改的课程信息”活动，完成输入

要修改的课程信息的工作后，进入“系统”泳道开展“验证课程信息”活动，验证课程信

息的完整性和有效性。如果信息验证通过，则继续执行“更新课程信息”活动，将修改后

的课程信息保存到数据库中。如果信息验证失败，则返回“用户界面”泳道，提示用户修

改信息并重新提交，否则提示修改成功。分叉和汇合分叉（Fork）

表示把一个单独的控制流分成两个或多个并发的控制流。汇合（Join）

表示两个或多个并发控制流的同步发生，一个汇合可以有两个或多个进入转移和一个输出转移。分叉和汇合在图形上都使用同步条来表示，同步条通常用一条粗的水平线表示。带分叉和汇合的活动图泳道“泳道”技术是将一个活动图中的活动状态进行分组，每一组表示一个特定的类、人或部门。每个泳道在活动图中都有一个唯一的名称，表示业务过程中的实体。在被划分为泳道的活动图中，每个活动都明确属于一个泳道，不可以跨越泳道，而转移则可以跨越泳道。带泳道的活动图典型案例【示例3-2】对象流包括依赖关系和对象的应用被称为对象流（ObjectStream）,对象流是动作和对象间的关联。在UML规范中，使用矩形表示对象，矩形内是该对象的名称。对象和动作之间使用带箭头的虚线连接，带箭头的虚线表示对象流。带对象流的活动图活动图的建模技术03对业务流程建模通常可以按照下列步骤，使用活动图对系统建模：

①确定活动图所关注的业务流程。②确定该业务流程中的业务对象。

③确定该工作流的起始状态和终止状态。

④从该工作流的起始状态开始，说明随着时间发生的动作和活动，并在活动图中把它们表示成活动状态或动作状态。

⑤将复杂的动作或多次出现的动作集合归并到一个活动状态，并对每个这样的活动状态提供一个可展开的单独的活动图。

⑥找出连接这些活动和动作状态的转移。

⑦如果工作流中涉及重要的对象，则也把它们加入到活动图中。“充值”用例是智慧校园系统中用户角色的一个功能，主要用于用户为个人账号充值，其具体的处理流程是：

用户首先登录智慧校园系统，然后选择“充值”功能。系统会显示当前校园卡的余额，并提示用户输入充值金额。用户输入充值金额后，

系统显示可充值方式，用户选择充值方式，系统调用第三方支付服务。支付成功后显示充值成功后的余额，支付失败则显示支付失败信息。①创建活动图②创建泳道③创建开始节点④创建活动”登录智慧校园”⑤按照任务分析结果，重复步骤④创建后续的主要活动状态⑥创建分支节点⑥创建分支节点⑦创建终止节点日常生活自助服务子模块用例图

活动图作为软件工程中的一种业务活动分析工具，能帮助我们精确地描述和理解业务流程。在活动图的建模技术中，我们学习如何对业务流程进行抽象和优化，这不仅培养了我们的逻辑思维能力，也锻炼了分析和解决问题的能力，这种能力在任何领域都是宝贵的。此外，活动图的分支、合并、分叉和汇合等元素，教会我们在面对复杂多变的情况时，如何灵活应对和有效协调。通过这样的学习和实践，我们不仅能够提升个人的专业技能，还能够在更广泛的社会领域中发挥积极作用。1.活动图2.活动图的组成元素3.活动图的建模技术

任务4

使用类实现系统结构分析

内容导图理解类图的基本概念。掌握类的抽象方法及其作用。掌握类的属性（Attributes）

和类的操作（Operation）。掌握类之间关系的表示方法。熟悉UML类图的绘制规范与工具。能够阅读和理解类图。能够熟练使用UML建模工具绘制符合规范的类图。能够使用类图进行系统设计。能够使用建模工具对系统进行建模。培养系统分析与设计能力，通过类图的应用，深入理解软件系统的整体结构和各组件间的交互关系。提升逻辑思维和抽象能力，能够将复杂的现实问题抽象为简洁明了的类模型。

智慧校园系统的需求建模阶段描述了系统的业务处理流程，接下来进入结构建模阶段。首先要从需求建模阶段的用例图、活动图去寻找和发现类，解析类之间的关系并用类图进行描述。请运用本节所学知识，完成如下任务：1.抽象出智慧校园系统充值管理子模块所有类；2.解析智慧校园系统充值管理子模块类之间的关系；3.绘制智慧校园系统充值管理子模块类图。类图概述01类图概述在UML中，类图

（ClassDiagram）

是最常用的一种静态模型，用于描述系统中类的静态结构。类图主要作用在于描述系统的构成方式，而不是系统的协作运行过程。通过类图，开发者可以清晰地理解系统的组成部分、各个部分的职责以及它们之间的交互方式。门禁子模块类图

通过门禁子模块类图我们可以了解到，

该模块包含用户类

（User）、面部信息类（FaceInfo）、出入记录类（AccessRecord）、出入记录管理类（AccessRecordManager）、面部信息管理类

（FaceInfoManager）。类02类类（Class）

是对一组具有相同属性、操作、关系和语义的对象的描述。类是对事物的抽象。它不是个体对象，而是描述一组对象的完整集合。类主要是由名称、属性和操作组成。用户类类的组成类必须各自有不同的类名称，类名称（Name）是一个字符串。类名一般采用小驼峰命名法，可以由数字、字母和下划线等符号组成，类名的长度没有限制。属性

（Attribute）

是已被命名的类的特性，它描述了该特性的实例可以取值的范围。

属性描述的一般语法格式为：可见性属性名：类型名［多重性］［=初值］{特性串}操作（Operation）是服务的实现，该服务可以由类的任何对象请求以影响其行为。

其标准语法格式为：可见性 操作名（参数表）：返回类型｛特性串｝。用户类的操作描述用户类属性接口接口（Interface）定义了一组操作的规范，但不包含这些操作的具体实现。在UML中，接口通常用一个带有“<<interface>>”标签的矩形来表示，接口名称放在矩形的顶部中心，接口的操作被列在接口名称下方的栏中。与类不同的是，接口中的操作不包含具体的实现，也没有属性部分。支付接口类的三种类型03实体类实体类具有永久的特性，这类似于数据库中的表一样用于保存系统的业务信息。在UML中，实体类的构造类型（Stereotype）

被设定为Entity。书籍实体类实体类图标形式边界类边界类（Boundary）

位于系统与外界的交接处，它在一个或多个角色和系统之间建立相互作用的模型。在UML中，边界类的构造类型（Stereotype）被设定为Boundary。书籍实体类边界类的图标形式控制类控制类（Control）是负责协调其他类的工作，它建立了一个或几个用例的行为模型。在UML中，控制类的构造类型（Stereotype）是Control。书籍管理模块控制类书籍控制类图标显示形式【示例4-1】从在线选课系统中的课程管理模块中找出所有的实体类、边界类和控制类。典型案例【示例4-1】类的关系04类的关系——依赖依赖（Dependency）

是一种使用关系，它说明了一个事物的变化可能影响到使用它的另一个事物，但反之未必。在UML中定义了4类基本依赖类型，

分别是使用（Usage）

依赖、抽象

（Abstraction）

依赖、授权

（Permis⁃sion）

依赖和绑定（Binding）

依赖。依赖关系类的关系——泛化泛化（Generalization）

是一般事物（称为父类或超类）

和较特殊事物（称为子类或孩子类）

之间的关系。在UML中，泛化使用从子类指向父类的实线箭头表示，指向父类的是一个空三角形。泛化关系类的关系——实现实现（Realization）

是类元（类）

之间的语义关系，关系中的一个类元（类）

描述了另一个类元（接口）

实现的契约。在UML中，实现关系是用一条带封闭箭头的虚线来表示，与泛化的符号很相似，这表示实现关系类似于一种继承关系。实现关系类的关系——关联关联（Association）

是一种结构关系，它描述了一个事物对象与另一个事物对象的相互联系。在UML中，关联关系是用一条直线表示。关联关系类的关系——关联在UML中，有4种可应用到关联的基本修饰：关联名、关联端的角色、关联端的多重性以及聚合与组合。

（1）关联名：关联可以通过命名的方式来描述关系的性质。

（2）角色：当一个类处于关联的某一端时，该类就在这个关系中扮演了一个特定的角色。

（3）多重性：表示一个关联的实例中有多少个相互连接的对象。

（4）聚合与组合：在实际建模中，有时往往需要对“整体/部分”的关系进行描述。这种关系在面向对象中就称为聚合。组合是聚合的一种形式，它具有强大的拥有关系，而且整体与部分的生命周期是一致的。【示例4-2】

分析图中类之间存在的关系。典型案例【示例4-2】类图的建模技术05对简单协作建模协作是动态交互在静态视图上的映射，协作的静态结构通过类图来描述。对协作建模要遵循如下策略：①识别要建模的机制。②对每种机制，识别参与协作的类、接口和其他协作，并识别这些事物之间的关系。③用协作的脚本检测事物。④把元素和它们的内容聚合在一起。协作是动态交互在静态视图上的映射，协作的静态结构通过类图来描述对数据库模式建模传统的E-R图只针对存储的数据，而类图则在此基础上，增加了行为建模的能力。使用类图对数据库模式建模时，要遵循的策略包括：①在系统中确定的类，它的状态必须超过其应用系统生命周期。②创建包含这些类的类图，并把它们标记成永久的。③展开这些类的结构信息，即详细的描述属性的细节，并注重关联和构造这些类的基数。④观察系统中的公共模式（如循环关联、一对一关联等），它们往往使物理数据库设计复杂化。⑤考虑这些类的行为，扩充对于数据存储和数据完整性很重要的操作。绘制智慧校园系统充值管理子模块类图（1）确定充值管理子模块功能。（2）基于功能，识别充值管理子模块主要类。（3）确定类之间的关系。①创建充值管理子模块类图②添加用户实体类User③

重复步骤②，添加任务分析中识别的其他类及其属性和操作④创建用户类

（User）

与充值记录类

（RechargeRecord）

之间的关联关系⑤创建充值管理类

（RechargeManager）

与其他类之间的依赖关系⑥创建充值方式类（RechargeMethod）

与其他类之间的实现关系充值管理子模块类图

通过类图的学习，我们不难发现，不同用户群体的关注点和需求是多元化的，这种多元化的需求，其实正是我们社会生活中多样性和差异性的体现。每个人都有自己的角色和定位，因此也会有不同的需求和期望。在我们的学习和生活中，也应该学会尊重和理解他人的需求和差异。当我们面对不同的声音和意见时，不应该急于否定或排斥，而是应该尝试去理解和接纳。只有这样，我们才能建立一个更加和谐、包容的社会环境。1.类图2.类的类型3.类之间的关系

任务5

使用状态机图实现系统

动态行为分析

内容导图掌握状态机图在UML中的定义、作用和应用范围。掌握状态机图的基本组成元素。掌握状态机图的建模方法。能够根据系统的需求规格说明书，绘制出符合UML规范的状态机图。能够通过分析状态机图，理解系统的动态行为和工作流程。培养严谨的逻辑思维与问题分析能力，能够更加系统地分析和理解复杂系统的动态行为。培养良好的规范意识和专业素养，能绘制符合UML规范的状态机图。

通过前面章节的学习，我们完成了智慧校园系统的需求建模，得出了系统的用例图和活动图。通过这两类图我们可以了解系统的业务处理过程，但对业务处理过程的处理状态间的转换了解仍不够，这不利于设计人员对系统业务的进一步理解，而状态机图能从对象的动态行为角度去描述系统的业务活动。请运用本节所学知识，完成如下任务：1.抽象出智慧校园系统用户登录的主要状态；2.分析智慧校园系统用户登录过程的主要事件；3.绘制智慧校园系统用户登录的状态机图。状态机图概述01状态机图概述状态机图是一种展示状态机的图，在UML1.x中称为状态图。状态机是一种行为，用于描述一个对象在其生命周期中的各种状态及状态的转换。状态机图用于对系统的动态方面建模。动态方面是指系统体系结构中任一对象按事件排序的行为，这些对象可以是类、接口、构件和节点。活动图强调对有多个对象参与的活动过程建模，而状态机图更强调对单个反应型对象建模。系统寝室报修维修单状态机图

通过寝室报修维修单状态机图我们可以了解到，报修维修单整个过程包含“未提交”、“已提交，待派单”、已派单，待处理”、“维修中”、“已删除”、“已完成”等6个状态。在最开始的“未提交”状态下，当用户执行删除维修单操作，则进入“已删除”状态；当用户执行提交维修单操作，则进入“已提交，待派单”状态。接下来，分派维修单，则进入“已派单，待处理”状态；接收维修单后，进入“维修中”状态；当维修单处理完毕，

最后进入“已完成”状态。状态机图的组成元素02状态状态（State）是指在对象的生命周期中满足某些条件、执行某些活动或等待某些事件时的条件或状况。状态机图中状态一般可以分为简单状态、初始/最终/选择状态和复合状态3种。简单状态简单状态是不包含嵌套的状态，在UML中表示为一个圆角矩形。简单状态主要组成元素有状态名称、进入/退出动作、内部转换和延迟事件。简单状态初始/最终/选择状态初始状态表示该状态机图或子状态的缺省开始位置，初始状态是用实心的圆表示。最终状态表示该状态机图或外围状态的执行已经完成，最终状态用内部含有实心圆的圆圈表示。一个状态机图中只能有一个初始状态，可以有多个最终状态。选择状态用于表示状态机图中的分支结构。初始/最终/选择状态复合状态复合状态，也被称作组合状态，是指包含有一个或多个嵌套状态机图的状态。在复合状态中，我们可以先将一部分细小的状态组合成一个状态机，把这个新的状态机作为总状态机图中的一个复合状态来呈现。复合状态又可以分为顺序复合状态和并发复合状态。顺序复合状态顺序复合状态又被称为非正交状态，是仅含一个状态机的复合状态。当顺序复合状态被激活时，只有一个子状态

（Substate）

会被激活。顺序复合状态【示例5-1】

在一个简单的咖啡机系统中，它的状态机图中包含一个顺序复合状态“冲泡”。这个顺序复合状态包含了几个子状态，如“加水”、“加热”、“冲泡”等。当用户启动咖啡机时，“冲泡”复合状态被激活，然后依次激活“加水”子状态，等待加水完成后再激活“加热”子状态，接着是“冲泡”子状态，在整个冲泡过程中，这些子状态是顺序

执行的，只有当前一个子状态完成后，才会进入下一个子状态。典型案例【示例5-1】自动咖啡机状态机图并发复合状态并发复合状态，也称正交复合状态，是包括两个或多个并发执行的子状态机的复合状态并发复合状态将复合状态分成若干个正交区域，每个区域都有一个相对独立的。并发复合状态历史状态历史状态是一个伪状态，其目的是记住从组合状态中退出时所处的子状态，当再次进入组合状态，可直接进入这个子状态，而不是再次从组合状态的初始状态开始。在状态机图中，历史状态使用图

表示。【示例5-2】

播放器中“继续播放上次未完成的列表”功能，播放器在顺序播放歌曲列表的模式下，如果用户停止了播放或者其他原因退出了播放器，重新播放后在上一次播放的节点（历史状态）

后继续顺序播放。典型案例【示例5-2】含历史状态的状态机图转换转换（Transition）是两个状态间的一种关系，表示对象将在当前状态中执行动作，并在某个特定事件发生或某个特定的条件满足时进入后继状态。当状态发生转变时，转换就被称为激活。在转换激活之前，称对象处于源状态；激活后，就称对象处于目标状态。转换由5部分组成：源状态（SourceState）、事件触发（EventTrigger）、监护条件（GuardCondition）、动作（Action）、目标状态（TargetState）。事件在状态机图中，使用事件来描述一个动作的产生，动作能够触发一个状态的转换。在UML中，事件可以分为信号事件、调用事件、变化事件、时间事件4种类型。调用事件时间事件变化事件信号事件【示例5-3】绘制全自动洗衣机工作过程的状态机图。典型案例【示例5-3】全自动洗衣机工作状态状态机图的建模技术03状态机图的建模技术使用状态机图对系统反应型对象建模时，应遵循如下策略：（1）选择状态机的语境（即建模对象），不管它是类、用例或是整个系统；（2）选择这个对象的初态和终态；（3）考虑对象可能在其中存在一段时间的条件，以决定该对象所在的稳定状态。从这个对象的高层状态开始，然后考虑它可能的子状态；（4）在对象的整个生命周期中，决定稳定状态的有意义的顺序；（5）决定可能触发从状态到状态的转换的事件。将这些事件建模为触发者，它触发从一个合法状态序列到另一个合法状态序列的转换；（6）把动作附加到这些转换上，并且附加到这些状态上；（7）考虑通过使用子状态、分支、汇合和历史状态，来简化状态机图；（8）核实所有的状态都是在事件的某种组合下可达的；（9）核实不存在死角状态，即不存在那种不能转换出来的状态；（10）通过手动或通过使用工具跟踪状态机，核对所期望的事件序列以及它们的响应。

智慧校园系统为确保系统信息安全，用户在进入系统前必须要登录系统，系统需要对用户身份进行校验。在智慧校园系统中用户校验在以下几种工作状态中转换：未登录、校验失败、校验码校验、用户名校验、用户口令校验和用户权限校验。状态之间转换的主要事件为：（1）未登录的用户通过登录功能成为系统中在线用户；（2）在输入用户信息之后，从未登录状态进入校验码校验状态；（3）在校验码校验状态中，当校验通过时转入用户名校验状态，否则转入校验失败状态；（4）在用户名校验状态中，当校验通过时将转入用户口令校验状态，否则转入校验失败状态；（5）在用户口令校验状态中，当口令校验成功时转入用户权限校验；（6）用户权限校验状态主要是对用户是否具有操作业务功能的权限进行判别；（7）校验失败状态是在显示校验失败信息之后返回未登录状态。①创建用户登录状态机图②添加开始元素③

重复步骤②，向状态机图添加任务分析中的其他状态。④根据任务分析中的描述，通过事件将不同的状态进行关联⑤重复步骤④，创建任务分析中的其他状态转换用户登录状态机图

状态机图是用于描述对象状态变化和事件触发的一种图形表示法。它不仅展示了对象在不同状态下的行为，还揭示了状态之间的转换关系。状态之间的转换需要明确的触发事件，我们在社会发展和个人成长中，每一次的进步和转变都需要具体的行动和努力，否则个人和社会也无法进步。其次，状态机图的构建过程中需要考虑所有可能的状态和转换，这要求我们培养全面和系统的思维方式，鼓励我们从宏观的角度审视问题，考虑各种可能性和潜在的影响，从而做出更加周全和深远的决策。通过学习和应用状态机图，我们能够更好地理解变化与稳定、行动与结果之间的关系，培养全面思考、精益求精的工匠精神，

以及对社会负责的公民意识。1.状态机图2.状态机图的组成元素3.状态机图建模任务6

使用交互图实现系统对象协作

分析内容导图理解交互图在UML中的定义、用途及其在系统分析和设计中的作用。掌握顺序图和通信图的基本组成元素。掌握交互图的建模方法。能够根据系统的需求规格说明书，绘制出符合UML规范的交互图。能够通过分析交互图，理解系统的动态行为和对象间的交互关系。培养从整体上理解和把握系统动态行为的能力，能将复杂的系统问题分解为一系列有序的对象间交互。增强沟通协作能力，能利用交互图清晰地表达设计意图和系统的动态行为。

交互图是UML中对对象间动态交互进行建模的两种主要图，包括顺序图和通信图。顺序图强调了对象间交互的时间顺序，而通信图则强调了对象间的关联关系。交互图主