软件工程的定义
软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术和管理方法。根据1993年IEEE的定义,软件工程是将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程,同时也是对这些方法进行研究的学科领域。
软件工程包含三个主要组成部分:方法、工具和过程。
方法: 为软件开发提供“如何做”的技术。它支持项目计划和估算、系统和软件需求分析、软件设计、编码、测试和维护。
工具: 为软件工程方法提供自动或半自动的软件支撑环境。目前已经建立有集成化的计算机辅助软件工程(CASE)环境。
过程: 定义了方法使用的顺序、要求交付的文档资料,为保证质量和协调变化所需要的管理及软件开发的各个阶段的里程碑。
软件工程的方法、工具、过程构成了软件工程的三要素,这些要素协同工作以实现软件项目的成功开发和维护。
软件工程的目标
软件工程的目标是在给定成本和进度的前提下,开发出具有以下特征的软件产品:
可修改性: 软件能够容易地进行修改和升级,以适应新的需求和环境。
可靠性: 软件在各种条件下都能够稳定运行,不易出现故障和错误。
有效性: 软件能够以高效的方式完成其预定的功能,不浪费资源。
可理解性: 软件的结构和代码易于理解,方便开发人员进行维护和改进。
可维护性: 软件容易进行维护,包括修复错误、更新功能和适应新的硬件或软件环境。
可重用性: 软件的模块或组件能够被有效地应用于其他系统或模块,以提高开发效率和降低成本。
可适应性: 软件能够适应不断变化的环境和需求,具有灵活性和可扩展性,以应对未来的挑战。
可移植性: 软件能够在不同的硬件平台、操作系统或环境中轻松移植和运行,而无需大量修改。
可跟踪性: 能够追踪软件开发和维护过程,以确保项目按照计划进行,随时了解项目的状态和进展。
可互操作性: 软件能够与其他软件或系统进行有效的交互和集成,实现数据和功能的共享。
这些目标共同确保了软件工程的成果能够满足用户的需求,具有良好的质量和可维护性,同时在开发过程中保持经济效益。
软件危机的概念
软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。它涉及两个主要方面的挑战:
总体而言,软件危机的核心问题在于供求关系失调、开发费用失控,导致进度拖延、可靠性差、难以维护。以下是软件危机的典型表现:
软件危机的典型表现
估计准确性问题: 对软件开发成本和进度的估计常常不准确,导致项目可能超过预算和延期。
用户满意度问题: 用户对“已完成的”软件系统不满意的现象经常发生,说明软件交付的产品与用户期望存在差距。
软件质量问题: 软件产品的质量往往不可靠,可能存在错误和缺陷,影响系统的稳定性和可靠性。
维护困难问题: 软件常常是不可维护的,难以进行更新、修复和扩展,增加了后续维护的难度。
文档不足问题: 软件通常没有适当的文档资料,缺乏详细的说明和指南,给维护人员带来困扰。
成本占比上升问题: 软件成本在计算机系统总成本中所占的比例逐年上升,使得软件开发变得经济不可持续。
生产率提高不足问题: 软件开发生产率提高的速度跟不上硬件的发展速度,也远远跟不上计算机应用普及深入的趋势,导致开发滞后。
这些表现共同构成了软件危机的临床症状,突显了传统软件开发模式在应对快速增长的需求和复杂性方面的困难。因此,软件工程的发展旨在解决这些问题,提高软件开发的质量和效率。
瀑布模型是一种经典的传统软件工程过程模型,它规定了六种软件工程活动的衔接次序,类似于瀑布流水的流程。
瀑布模型的优点:
有效的管理图示: 提供了清晰的开发流程图,有助于制定软件开发计划、进行成本预算和组织开发力量。
阶段评审和文档控制: 在每个阶段都进行评审和文档控制,有助于有效地对整个开发过程进行监控和指导,确保软件产品及时交付并达到预期的质量要求。
项目控制和管理: 瀑布模型为项目提供了明确的阶段,使得项目的控制和管理更为直观和可操作。
瀑布模型的缺点:
缺乏灵活性: 瀑布模型要求严格按照阶段顺序进行,缺乏对变更的灵活响应,难以适应项目需求的变化。
无法解决需求问题: 当软件需求不明确、不准确或需要不断完善时,瀑布模型可能导致开发困难,因为需求的变化在后期难以实施。
复用和集成支持不足: 瀑布模型较难支持组件的复用和多项开发活动的集成,这在现代软件开发中是一个重要的挑战。
为了解决瀑布模型的这些缺点,近年来出现了多种其他软件开发模型,如螺旋模型、原型模型等,它们更注重灵活性、迭代开发和对需求变化的敏捷响应。这些模型更适应复杂、变化迅速的软件开发环境。
原型模型的这些优点使其成为处理需求不确定性和促进团队合作的有力工具。然而,需要注意的是,在使用原型模型时,及时的用户反馈和有效的沟通是确保成功的关键因素。
螺旋模型是一种软件开发模型,结合了瀑布模型和原型模型的优点,并引入了新的成分——风险分析。以下是螺旋模型的组成和特点
模型组成
需求定义:
风险分析:
工程实现:
评审:
模型特点
结合优点:
增加新成分—风险分析:
循环迭代:
螺旋模型通过引入风险分析和迭代开发的方式,提高了项目的适应性和灵活性。它适用于大型、复杂、风险较高的项目,为项目的成功提供了更多的保障。
螺旋模型优点与问题
优点
集成了瀑布模型和原型的优点:
需求分析和软件实现相互依赖、紧密联系:
用户参与决策:
形式化的需求说明书:
便利的项目管理:
问题
相对开发周期较长:
开发成本较大:
螺旋模型的优点在于其综合了不同模型的优势,但在实际应用中需要根据项目的特点权衡好开发周期和成本的关系。
软件生存周期
软件生存周期 如同普通事物一样,都存在生命周期,即孕育、诞生、成长、成熟和消亡等阶段。软件产品从形成概念开始,经过开发、使用和维护,直到最后退役的全过程。 软件生存周期包括:软件定义、软件开发、软件使用和维护3个部分。
软件生存周期细划为:可行性研究、需求分析、概要设计、详细设计、实现(编码)、测试、使用、维护、退役等几个阶段
可行性研究(Feasibility Study):
需求分析(Requirements Analysis):
概要设计(System Design):
详细设计(Detailed Design):
实现(编码)(Implementation/Coding):
测试(Testing):
使用(Deployment):
维护(Maintenance):
退役(Retirement):
每个阶段都有其独特的任务和活动,而软件的生命周期管理有助于确保软件项目按计划、质量和成本的要求进行。
确切地说,软件需求分为三个主要层次,包括业务需求、用户需求和系统需求(其中包括功能和非功能需求):
业务需求(Business Requirements):
用户需求(User Requirements):
功能需求(Functional Requirements):
非功能需求(Non-functional Requirements):
这三个层次的需求相互关联,业务需求指导用户需求,而用户需求进一步细化为功能和非功能需求,以便开发人员能够明确实现的目标。需求管理的有效性对于确保软件项目按照期望的方式进行至关重要。
初步需求获取是软件开发过程中至关重要的一步,而以下是一些常用的初步需求获取技术:
访谈与会议: 通过与关键利益相关者(如客户、最终用户、业务分析员)进行面对面的访谈和会议,获取他们的见解、期望和需求。这有助于深入了解业务流程和系统期望。
观察用户的工作流程: 观察和分析用户在实际工作环境中的操作和流程,以识别潜在的问题、瓶颈和改进点。这种方法有助于捕捉实际需求和用户体验方面的细节。
建立联合工作小组: 将开发团队成员、最终用户和其他利益相关者组成一个联合工作小组。通过协作和讨论,团队能够共同理解需求,促进信息共享,确保各方的期望得到考虑。
这些技术通常结合使用,以确保从多个角度收集准确和全面的需求。通过有效的初步需求获取,可以建立一个坚实的需求基础,为后续的系统设计和开发工作提供指导。
数据流图是一种强调数据流动和处理过程的信息系统建模技术。基于IPO模型(输入-处理-输出模型),软件的功能可被视为对数据进行格式转换的过程,将输入数据转换为输出数据。以下是数据流图建模的本质:
数据传递和变换:
自顶而下,逐步求精分解:
信息处理系统的构成:
通过数据流图,分析人员可以深入了解系统的数据流动,识别重要的转换过程,并确保系统满足用户的需求。这种方法使得软件功能需求得以清晰呈现,为系统设计和开发提供了有力的指导。
# UML类表示领域概念模型
在UML中,通过类来表示概念,而类图则展示了领域概念模型。在需求分析的早期阶段,并不需要一次性列举所有类的属性和方法。最初只需标识类名,随着分析和设计的推进,逐步完善属性列表和方法列表。
## UML类的三个部分:
图示中表达了元素的形式。
UML类之间的关系主要包括继承、聚合、关联和依赖。继承表示子类重用父类的属性和操作,子类的对象也是父类的对象,有时也称为泛化。
UML将聚集关系分为两种:
普通聚集关系: 一个部件对象可以同时参与多个整体对象。
构成关系: 限定一个部件对象在任意时刻只能参与一个整体类的对象,部件类对象与整体类对象共存亡。
# 关联关系
关联关系表示两个类的对象之间存在着用于消息传递的稳定通道。在课程注册管理系统中,例如,“学生”类、“老师”类与“课程设置”类之间存在关联关系,因为“课程设置”与选课学生和授课老师有关,学生和老师需要查询课程设置的相关信息。
通常,两个类的对象之间存在数量对应关系,这是业务规则的具体表现。在分析和设计推进到一定阶段后,应在聚集、构成和关联关系的表示边上明确标示,如表示每个“课程设置”对象应不少于10个、不多于50个选课学生。
# 依赖关系
依赖关系表示依赖类B的对象需要向被依赖类A的对象传递消息,且被依赖类A可作为依赖类B操作的形参类型。依赖关系是临时性的消息传递通道,操作完成后通道消失。
例如,“订单”包中的类仅依赖于“数据库接口”包中的类(接口),不需要建立关联关系。依赖关系是关联关系的弱化,表示被依赖类的变化会影响到依赖类。
依赖的强化是关联,关联的强化是聚合,聚合的强化是构成。
面向数据流的设计方法(SD方法)
面向数据流的设计方法,即结构化设计法(SD方法),在需求阶段通过对数据流的分析生成数据流图和数据字典,以此为基础设计软件结构。
数据流图描述了信息在系统内部加工和流动的情况。该方法根据数据流图的特性定义了两种映射:变换流和事务流。这两种映射能够机械地将数据流图转换为程序结构。
方法的目标是为软件结构设计提供系统的途径,使设计人员能够对软件有一个整体的认识,并通过分析数据流的特性来定义程序结构。
稳定性差:
可修改性差:
重用性差:
综合而言,这些问题强调了在处理变化、修改和重用时,结构化分析和设计技术可能面临的一些挑战。现代的软件开发方法和架构设计趋向于采用更灵活、模块化且面向对象的方法,以更好地满足不断变化的需求和提高系统的可维护性、可修改性和可重用性。
面向对象需求分析方法
面向对象(Object-Oriented, 简称OO)的需求分析方法通过提供对象、对象间消息传递等语言机制,让分析人员在解空间中直接模拟问题空间中的对象及其行为,从而削减了语义断层,为需求建模活动提供了直观、自然的语言支持和方法学指导。
为了在解空间模拟现实问题并与人类的思维习惯相一致,OO方法学包容了以下核心概念:
对象
示例:大型客机可视为对象,具有位置、速度、颜色、容量等属性,可以执行起飞、降落、加速、维修等操作。
类
示例:直升飞机、大型客机、轰炸机可归为飞行器类,共同属性包括位置、速度和颜色,共同操作包括起飞、降落、加速和维修。
继承
示例:飞行器、汽车和轮船可归于交通工具类,飞行器类可以继承交通工具类的某些属性和操作。
聚集
示例:飞机由发动机、机身、机械控制系统、电子控制系统等构成。
消息
示例:直升飞机响应轮船的急救信号,执行救援操作。
面向对象 = 对象 + 类 + 继承 + 聚集 + 消息。
【说明】
假设你已完成一个四则运算自动生成软件,并提交给用户使用。然而,用户对该软件很不满意,陆续提出新的需求,要求你在原有软件基础上进行扩展。例如,除了整数以外,还要支持真分数的四则运算,例如:1/6+1/8=7/24;程序要求能处理用户的输入,判断对错,累积分数;程序支持可以由用户自行选择加、减、乘、除运算等。
【问题1】什么是软件危机,产生软件危机有哪些原因?
【问题2】软件开发过程中,获取用户的需求很重要。谈谈常见的初步需求获取技术?
【问题3】如果你负责开发该软件,谈谈你准备采用哪种软件开发模型(如,瀑布模型、螺旋模型、原型模型等)并说明理由。
【问题4】描述软件维护的类型及工作内容,说明本案例属于哪种类型软件维护。
软件危机指的是在软件开发中出现的一系列问题和挑战,使得软件项目难以按照预定计划和预算完成,导致项目失败或者交付的软件无法满足用户需求。产生软件危机的原因主要包括:
复杂性增加: 软件系统的复杂性随着功能的增加而增加,导致难以理解和维护。
变更需求: 用户对软件需求的频繁变更使得原有的开发计划失效,增加了开发的难度。
技术水平: 在软件开发初期,技术水平相对较低,导致开发过程中出现许多错误,增加了修复的成本。
项目管理: 缺乏有效的项目管理和控制,导致项目进度延误和成本超支。
缺乏标准: 缺乏统一的软件开发标准和规范,导致开发过程中的混乱。
获取用户需求的技术包括:
面谈: 直接与用户交流,通过问答方式获取用户需求。
问卷调查: 发放问卷收集用户对系统期望和需求的信息。
头脑风暴: 团队成员集体讨论,汇总各种可能的需求。
原型设计: 制作简单的原型,让用户更直观地了解系统,提供反馈。
用户观察: 观察用户在实际操作中的行为,发现他们的需求和问题。
在这个案例中,可能选择迭代模型。原因如下:
用户需求变化: 由于用户陆续提出新的需求,迭代模型允许灵活地进行修改和扩展,适应需求的变化。
快速反馈: 每次迭代都可以产生一个可运行的软件版本,用户可以快速看到实际效果,提供反馈,有助于及时调整和改进。
降低风险: 通过多次迭代,逐步完善软件,有助于降低项目失败的风险,增强项目的可控性。
软件维护包括以下类型:
纠错性维护(Corrective Maintenance): 修复已发现的错误和缺陷,确保软件正常运行。
适应性维护(Adaptive Maintenance): 针对环境变化(如操作系统升级、硬件更换等)进行调整,以适应新的环境。
完善性维护(Perfective Maintenance): 对软件进行优化和改进,以提高性能、可维护性和用户体验。
预防性维护(Preventive Maintenance): 通过识别和修复潜在问题,防止未来可能出现的错误。
在这个案例中,由于用户提出了新的需求,需要对原有的四则运算自动生成软件进行扩展,支持真分数的四则运算等功能。这属于适应性维护,因为需要对软件进行调整以适应新的需求和变化。同时,对用户输入进行判断、累积分数等操作也可能涉及到纠错性维护和完善性维护,确保软件的正确性和性能。
RUP(Rational Unified Process)模型是一种面向对象的软件开发过程,它强调迭代和增量的开发方式。RUP包含以下几个关键特点:
迭代性: 将整个软件开发过程划分为多个迭代,每个迭代都包含系统的部分功能。每次迭代都可以产生一个可执行的软件版本。
增量性: 每个迭代都为系统添加新的功能,逐步完善软件。这种增量的方式使得软件在开发过程中逐渐变得更加完善。
用例驱动: RUP强调用例驱动的方法,即从用户的角度出发,明确定义系统的功能和行为。
体系结构驱动: 强调系统的体系结构设计,确保系统的结构合理、可扩展和易维护。
用例图是一种描述系统功能的图,展示了系统的各个用例(功能)以及它们之间的关系。在这里,我们可以描述一个简单的餐厅点餐系统的用例图:
[图形描述餐厅点餐系统的用例图]
在这个用例图中,可能包括顾客和管理员两个主要角色,以及顾客点菜、查看菜单、结账等用例,管理员管理菜单、查看订单等用例。用例之间的关系可以用关联线表示。
在面向对象设计中,可以使用以下两种图描述用例实现过程:
类图(Class Diagram): 类图表示系统中的类以及它们之间的关系。每个用例通常对应一个类,类中包含了属性和方法,描述了用例的结构和行为。
交互图(Interaction Diagram): 交互图包括时序图和协作图,用于描述系统中对象之间的交互过程。时序图展示了对象之间消息的顺序,协作图展示了对象之间的协作关系。
区别:
方法论: 面向对象方法强调对象、类、继承等概念,注重对系统进行抽象和建模;而结构化方法则更注重流程、模块、数据流等方面的设计。
复用性: 面向对象方法更注重通过类和对象的复用来提高系统的可维护性和灵活性;结构化方法在复用方面相对较弱。
模块化: 面向对象方法通过类的封装实现了模块化设计,提高了系统的可维护性;结构化方法则通过模块的划分来实现模块化设计。
联系:
目标: 都旨在通过良好的设计和开发方法来构建可靠、可维护、可扩展的软件系统。
开发过程: 都采用迭代、逐步完善的开发方式,强调分阶段、模块化的设计。
需求分析: 都注重对用户需求的理解和捕捉,以确保最终系统符合用户期望。
某医院拟开发病人监控系统。该系统通过各种设备监控病人的生命特征,并在生命特征异常时向医生和护理人员报警。该系统的主要功能如下:
(1)本地监控:定期获取病人的生命特征,如体温、血压、心率等数据。
(2)格式化生命特征:对病人的各项重要生命特征数据进行格式化,然后存入日志文件并检查生命特征。
(3)检查生命特征:将格式化后的生命特征与生命特征范围文件中预设的正常范围进行比较。如果超出了预设范围,系统就发送一条警告信息给医生和护理人员。
(4)维护生命特征范围:医生在必要时(如,新的研究结果出现时)添加或更新生命特征值的正常范围。
(5)提取报告:在医生或护理人员请求病人生命特征报告时,从日志文件中获取病人生命特征生成特征报告,并返回给请求者。
(6)生成病历:根据日志文件中的生命特征,医生对病人的病情进行描述,形成病历存入病历文件。
(7)查询病历:根据医生的病历查询请求,查询病历文件,给医生返回病历报告。
(8)生成治疗意见:根据日志文件中的生命特征和病历,医生给出治疗意见,如处方等,并存入治疗意见文件。
(9)查询治疗意见:医生和护理人员查询治疗意见,据此对病人进行治疗。
现采用结构化方法对病人监控系统进行分析与设计,获得如图3-1所示的顶层数据流图和图3-2所示的1层数据流图。
【问题1】使用说明中的词语,给出图1中的实体E1~E3的名称。
【问题2】使用说明中的词语,给出图2中的数据存储D1~D4的名称。
【问题3】
(1)图2中缺失了4条数据流,使用说明、图3-1和图2中的术语,给出数据流的名称及其起点和终点。
(2)说明实体E1和E3之间可否有数据流,并解释其原因。
【问题5】描述变换型数据流图映射到软件结构的步骤。
图1顶层数据流图
图2 1层数据流图
(1) 图2中缺失了4条数据流,使用说明、图3-1和图2中的术语,给出数据流的名称及其起点和终点。
(2) 说明实体E1和E3之间可否有数据流,并解释其原因。
在图2中,E1(病人监控系统)和E3(护理人员)之间没有直接的数据流。这是因为护理人员通过报告请求(数据流3)与系统进行交互,而不是直接与病人监控系统通信。系统负责处理这些请求并向护理人员提供相应的报告。
识别加工(Processes): 从数据流图中识别出所有的加工,这些加工将映射到软件中的模块或函数。
识别数据存储(Data Stores): 识别出数据流图中的数据存储,这些数据存储将映射到数据库或文件系统。
识别数据流(Data Flows): 识别出数据流,这些数据流表示信息在系统中的流动。它们将映射到函数调用或模块之间的数据传递。
确定外部实体(External Entities): 识别外部实体,这些外部实体表示系统之外的实体,如用户或其他系统。它们将映射到系统与外部环境的接口。
绘制结构图(Structure Chart): 根据识别出的加工、数据存储、数据流和外部实体,绘制结构图,该图表示软件系统的结构和模块之间的关系。
明确接口和数据传递: 在结构图中明确每个模块的接口和数据传递方式,确保系统各部分之间的协同工作。
验证与调整: 验证结构图的合理性,并根据需要进行调整,确保系统结构满足设计要求和性能要求。
【说明】
For years, programmers in industry have claimed that by working collaboratively, they have produced higher-quality software products in shorter amounts of time. But their evidence was anecdotal and subjective: “It works” or “It feels right.” To validate these claims, we have gathered quantitative evidence showing that pair programming—two programmers working side by side at one computer on the same design, algorithm, code, or test—does indeed improve software quality and reduce time to market. Additionally, student and professional programmers consistently find pair programming more enjoyable than working alone.
Yet most who have not tried and tested pair programming reject the idea as a redundant, wasteful use of programming resources:“Why would I put two people on a job that just one can do? I can’t afford to do that!” But we have found, as Larry Constantine wrote, that Two programmers in tandem is not redundancy; it’s a direct route to greater efficiency and better quality.”
【问题 1】什么是结对编程(pairwise programming)?
【问题 2】结对编程存在什么优缺点?
【问题 3】结合文中对结对编程的讨论,谈谈个人软件开发流程和团队开发流程?
**结对编程(Pair Programming)**是一种软件开发实践,两名程序员共同在同一台计算机上合作完成设计、算法、编码或测试等任务。在结对编程中,一位程序员是“驾驶员”(Driver),负责具体的实际编码工作,而另一位程序员是“观察员”(Observer)或“导航员”(Navigator),负责审查代码、提出建议和思考更高层次的设计问题。这两名程序员经常交换角色,以保持合作的平衡。
优点:
缺点:
个人软件开发流程:
团队开发流程:
在实践中,个人软件开发者可能更注重独立性和自主决策,而团队开发流程则更强调协作、沟通和共享。在团队中,可以根据项目的性质和团队成员的特点选择适当的开发方法,有时候也可以结合个人的独立工作和团队的协作方式,以达到最佳的开发效果。
public class Animal {
public void move(){}
}
public interface ICanEat {
public void eat();
}
public class Dog extends Animal implements ICanEat {
public void eat() { }
public void bark(){}
}
+-------------------+ +-----------------+ +----------------+
| Animal | | ICanEat | | Dog |
+-------------------+ +-----------------+ +----------------+
| | | | | |
| | | | | |
| + move() | | + eat() | | + eat() |
| | | | | + bark() |
+-------------------+ +-----------------+ +----------------+
在这个 UML 类图中:
Animal
类具有一个方法 move()
。ICanEat
接口具有一个方法 eat()
。Dog
类继承自 Animal
类,同时实现了 ICanEat
接口。它具有 move()
方法(来自继承)和 eat()
方法(来自接口实现),以及自己独有的 bark()
方法。关系说明:
@startuml
class Animal {
+move()
}
interface ICanEat {
+eat()
}
class Dog {
+eat()
+bark()
}
Animal <|-- Dog
ICanEat <|.. Dog
@enduml
这个UML类图表示了Animal类、ICanEat接口和Dog类之间的关系。类之间的箭头表示继承关系或实现关系。Animal类是一个基类,Dog类继承了Animal类并实现了ICanEat接口。
这段代码是使用PlantUML语言编写的,用于生成UML用例图,表示旅游景区指南系统的参与者和用例关系。你可以按照以下步骤将其用于生成UML图:
在线编辑器: 使用在线PlantUML编辑器,如PlantText或PlantUML Editor。将代码粘贴到编辑器中,然后它会为您生成UML图。
本地环境: 如果你想在本地生成图,需要安装PlantUML,并使用文本编辑器创建一个包含这段代码的文件。然后,在命令行中运行PlantUML来生成图。
安装: 从官方网站下载PlantUML,并按照说明安装。
命令行: 安装完成后,在命令行中运行PlantUML,例如:
plantuml yourfile.uml
将yourfile.uml
替换为实际的文件名。
查看图: 运行命令后,它将生成一个图像文件(例如PNG)。使用图像查看器打开图像文件以查看UML图。
旅游景区指南系统基于 Spring Boot 框架和 Vue.js 框架实现了景区指南信息的浏览和发布。使用该系统的角色有未授权用户、已授权用户、后台管理员。允许未授权用户使用系统进行注册账户、浏览景点介绍、浏览景点评论、搜索景区;已授权用户除了具有浏览景点介绍、浏览景点评论、搜索景区、功能权限外,还能够登录系统、发表景点评论、订购门票。已授权用户订购门票时,借助微信系统支付订单。后台管理员是已授权用户,可以管理用户信息、管理景区信息、管理景点信息等。
1)请分析旅游景区指南系统中的系统参与者有哪些?
2)分析不同参与者关联的用例,并根据分析结果绘制出旅游景区指南系统的 UML 用例图。
未授权用户:
已授权用户:
后台管理员:
UML 用例图:
+------------------------+ +------------------------+ +------------------------+
| Unauthorized User | | Authorized User | | Back-End Administrator|
|------------------------| |------------------------| |------------------------|
| + RegisterAccount() | | + Login() | | + ManageUserInfo() |
| + BrowseSpotIntro() | | + PostComment() | | + ManageScenicInfo() |
| + BrowseSpotComments() |--------| + OrderTicket() | | + ManageSpotInfo() |
| + SearchScenic() | | + BrowseSpotIntro() | +------------------------+
+------------------------+ | + BrowseSpotComments() |
| + SearchScenic() |
+------------------------+
这是一个简化的 UML 用例图,未画出具体的关系线。关系线通常包括关联关系(association)、继承关系(inheritance)、包含关系(include)等。根据系统的实际需求,可以在用例图中添加适当的关系以更准确地表达参与者和用例之间的关系。
用例图的关联如下:
UML 用例图示例:
@startuml
left to right direction
actor "未授权用户" as UnauthorizedUser
actor "已授权用户" as AuthorizedUser
actor "后台管理员" as Admin
rectangle "旅游景区指南系统" {
UnauthorizedUser --|> (注册账户)
UnauthorizedUser --|> (浏览景点介绍)
UnauthorizedUser --|> (浏览景点评论)
UnauthorizedUser --|> (搜索景区)
AuthorizedUser --|> (登录系统)
AuthorizedUser --|> (发表景点评论)
AuthorizedUser --|> (订购门票)
AuthorizedUser --|> (浏览景点介绍)
AuthorizedUser --|> (浏览景点评论)
AuthorizedUser --|> (搜索景区)
Admin --|> (管理用户信息)
Admin --|> (管理景区信息)
Admin --|> (管理景点信息)
}
@enduml
这个用例图简要展示了系统的参与者及其关联的用例。
这段代码是使用PlantUML语言编写的,用于生成UML用例图,表示旅游景区指南系统的参与者和用例关系。你可以按照以下步骤将其用于生成UML图:
在线编辑器: 使用在线PlantUML编辑器,如PlantText或PlantUML Editor。将代码粘贴到编辑器中,然后它会为您生成UML图。
本地环境: 如果你想在本地生成图,需要安装PlantUML,并使用文本编辑器创建一个包含这段代码的文件。然后,在命令行中运行PlantUML来生成图。
安装: 从官方网站下载PlantUML,并按照说明安装。
命令行: 安装完成后,在命令行中运行PlantUML,例如:
plantuml yourfile.uml
将yourfile.uml
替换为实际的文件名。
查看图: 运行命令后,它将生成一个图像文件(例如PNG)。使用图像查看器打开图像文件以查看UML图。
某图书管理系统的功能如下:
①读者登录系统后,可以查询信息、预约图书和续借图书;
②图书管理员登录系统后,可以查询信息、管理读者信息和图书信息以及进行借书和还书的操作;
③读者还书时,如果超过预期时间,则图书管理员要按照图书馆规定对读者进行罚款;
④后台管理员登录系统后可以维护系统
请分析需求并回答以下问题:
(1)请分析需求中的系统参与者有哪些?
(2)根据第(1)题的分析结果,进一步分析和每个参与者关联的系统用例。
(3)使用UML用例图可视化第(1)题和第(2)题的分析结果。
参考答案:
(1)读者、图书管理员和管理员;
(2)读者:登录、预约图书、续借图书、信息查询;
图书管理员:登录、信息查询、读者信息管理、图书信息管理;
管理员:登录、系统维护
(3)用例图参考图如下:
某医院拟开发一个分布式患者监护系统(PMS: Patients Monitoring System)。PMS将用于监视病房中每个患者的重要生理信号(如体温、血压、脉博信号等),并能定时更新和营理患者的病历。此外,当患者的生理信号超过医生规定的安全范围时,系统能立即通知护理人员,并且护理人员在需要时可随时通过系统产生某患者有关报告。
PMS的主要功能为:
① 通过一个病床监视器实现本地监测,以获得患者的生理信号。
② 在护士办公室实现中央监测
③ 更新和管理患者病历
④ 产生患者情况的报告以及报警信息
问题:
(1)请分析PMS的数据源点和数据终点分别是什么?
(2)根据需求描述,PMS可以分解成哪几个数据加工?
(3)根据第(1)题和第(2)题的分析结果,绘制1层数据流图。
参考答案:
(1)PMS的数据源是患者和护士;数据终点是护士;
(2)PMS可以分为本地监测、中央监测、产生报告和记录患者生理数据四个数据加工
(3)1层数据流图参考图如下: