软件建模技术 课件 任务1 初识软件建模、任务2 使用用例图实现系统需求分析

任务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.

用户在