SCI论文（www.lunwensci.com）
摘 要 ：需求分析阶段的主要任务是理解客户的真正需求,即了解客户需要一款什么样的软件,该阶段是整个软件开发过 程的输入和基础。随着软件需求的与日俱增,软件的规模与复杂程度也在不断增大,现行条件下的统一建模语言(UML)的缺 陷也在不断增高,因此,需要在原有的基础上进行修改和优化,避免过度建模、可读性低、不能表达用户实际需求等根本性问 题,这些变化使得开发人员更好地理解用户需求,从而提升产品的开发效率以及使用质量。
关键词 ：需求分析,统一建模语言,缺陷分析,改善策略
DefectAnalysis and Improvement Strategy ofUnified Modeling Language
LIU Yaoyuan, ZHAO Jianzhe
(Northeastern University, Shenyang Liaoning 110167)
【Abstract】：The main task in the requirement analysis phase is to understand the customer's real needs, that is, to know what kind of software the customer requires. This phase serves as the input and foundation for the entire software development process. As software requirements continue to increase, the scale and complexity of the software also keep growing, thereby exacerbating deficiencies within the current Unified Modeling Language (UML). Therefore, it is necessary to make modifications and optimizations on this basis to avoid issues such as over- modeling, low readability, and inability to express actual user requirements. These changes will allow developers to better understand user needs, thereby enhancing the efficiency and quality of product development.
【Key words】：requirement analysis;UML;defect analysis;improvement strategy
1.
引言
随着软件工程产品需求的不断复杂化以及软件产品 规模的扩大化,开发人员需要用更加合理有效的建模方 法以及使用工程学的手段来进行软件开发,但是现行条 件下的软件开发流程,模型和技术手段并不是十分行 之有效。据 IEEE 统计,目前软件的成功率约为 25%, 75% 的软件是失败的。在这 75% 的失败中,约有 50% 以上的软件是在需求分析阶段存在问题 [1]。因此,解决 需求分析阶段的矛盾,对于降低整个软件开发生命周期 的成本、时间等具有重要意义。
软件开发的第一阶段是需求分析,该阶段的成果物 是需求说明文档,其中产生的对象模型用来分析识别系 统的对象与类以及它们之间的静态关系,主要用到类图 和对象图 ;动态模型用来展现系统的内部行为、时序关系及状态变化,包括活动图、时序图和状态图 [2],开发 人员需要与用户之间共同确认需求分析说明文档,但是 用户可能对于高度集成化的具有继承封装特点的不同类 型的 UML 图产生疑惑,从而导致双方在交流方面的困 难,在这种情况下, UML 图不能十分清晰明了地表达 出用户的需求,当开发完成后,用户可能会发现这个产 品并不是自己所想要的,甚至在开发过程中,产品的需 求会不断地被更改,因而导致了软件产品的开发超时, 超出预算甚至失败等。特别对于大型复杂系统如 ERP 等,其规模和设计都比较复杂,传统的需求分析方法已 经不能满足要求,存在开发人员不能识别业务需求书、 需求反复确认等问题,影响开发效率 [3]。
因此,需要在传统统一建模语言的基础上进行优化 和改善,以促进业务人员与软件开发人员之间的高效交流,从而清晰化软件开发的需求,并进一步提高系统设 计的效率以及软件产品交付的最终成功率。
2 软件开发的变革
2.1 模型变革
敏捷软件开发方法逐渐取代了传统的瀑布模型,已 经引领了软件工程的新趋势,它以其对不断变化的需求 的灵活反应机制、早期且连续交付有价值产品的实践, 以及强调团队间协作和项目持续改进的理念,特别是在 用户需求模糊时,敏捷过程对于建立小型软件模型极为 有用 [4]。在当今的商业环境中, 变化快速而无法预知, 这使得整个软件开发生命周期需要具有极高的适应性。 相较之下,瀑布模型缺乏处理需求变动的灵活性,因为 在初期就固定了项目规划,很难灵活处理后期可能出现 的需求更改。敏捷开发则通过迭代式的短周期创新和早 期交付,频繁地与用户接触并获取反馈,大大降低了由 于需求变化带来的风险。此外,敏捷开发强调的团队协 同和持续反馈机制,加上定期回顾和持续改进的原则, 都有助于提升最终的产品质量和客户满意度。
2.2 微服务架构
微服务架构逐渐取代传统的单体架构。微服务架构将 应用程序划分为一系列小型、自包含的服务设计模式, 与 传统的单体架构形成对比。单体架构虽开发简便,但随 着应用规模的增长,其可维护性和扩展性面临挑战。相 反,微服务架构提供了更高的灵活性和可伸缩性,降 低了复杂性,有助于持续集成和交付,并提高了容错能 力。因此,微服务架构在满足现代软件开发灵活性、可 伸缩性和容错等需求方面表现优异,被广泛采用。
2.3 用户参与
与早期的瀑布模型等传统软件开发模型相比,现代 软件开发流程更加强调用户的参与。在传统模式下,开 发团队主要依据预先设定的需求规格进行开发,然后将 所开发的最终产品交给用户,这种模式往往无法做出及 时调整来适应用户需求的变化,可能导致产品与实际使 用者需要的解决方案之间存在差距。然而,在现代敏捷 开发和 DevOps 等理念中,持续性的用户参与成为了一 种新的常态。开发团队在整个开发过程中频繁获取并利 用用户反馈,以确保软件解决方案始终满足实际用户需 求。这对于提高产品质量和开发效率非常有利,能促使 产品更准确地解决用户问题,从而赢得市场竞争优势。 此外,在开源软件项目中,用户不仅是产品的消费者还 同时是产品的改进者,这也体现了用户参与推动软件社 区化发展的趋势。因此,可以认为用户参与已经成为现 代软件开发的重要特征和驱动力,其作用主要体现在准确把握用户需求、提升开发效率以及推动产品创新和社 区化发展等方面。
3 UML 语言面临的困境
在传统的面向对象开发模型的瀑布模型中,软件开 发依照阶段分步进行,流程固定,模式单一, UML 图在 需求分析中被确定之后不会经历过多的改动,但是软件 是开发出来的而不是被成批制造出来的 [5]。当今敏捷模 型被引入软件开发并广泛使用,在各个阶段文档可能会被 修改。UML 图作为复杂大型的覆盖继承,实现依赖关联 等众多复杂关系的面向对象业务流程图可能会经历大规 模的修改,甚至可能导致与开发团队提供的代码不一一 对应, 其复杂性逐渐制约了其发展。同时, UML 提供 的 14 种类型图, 每一种图都有特定的规则以及独特的符 号,系统缺乏专业知识的用户,可能无法理解这些细节, 从而产生沟通障碍,制约了需求的进一步提取和分析。
UML 在解释性方面具有局限性,因为其提供的工具 有限,无法在用户界面和用户体验以及人机交互方面提 供更高的服务。在用户体验设计方面,用例图和活动图 无法充分表示用户界面设计,包含元素布局、交互动画 等,也无法感知用户使用的情感体验。在界面设计方面, UML 无法直观地描述按钮的位置、颜色、尺寸等,也无 法描述页面的布局和排版细节。在交互逻辑方面, UML 在处理人机交互逻辑时,效果并不理想,比如,在描述 点击按钮后的系统响应过程,需要绘制多个 UML 图, 并配以大量的文字说明。同时,由于 UML 图是静态 的,无法模拟实际用户与系统的交互过程,因此通常需 要专门的原型设计工具或用户体验设计工具来实现。
UML 可能导致过度工程化,即在项目中投入的工 程化努力超过了实际价值。在敏捷开发模式下,绘制 完整的 UML 图是一个消耗时间,消耗精力的过程,但 创建和维护这些图需要花费大量的人力物力,如果一个 UML 图只被很少的人使用,或者根本没有被使用,那么 制作 UML 图的时间和精力就会被浪费在敏捷开发中。强 调的是快速反应以及灵活应对变化,更加关注有效的代 码和可工作的软件,而不是大量的文档和模型,这意味 着在敏捷开发环境中过度的 UML 建模会是一种浪费, 比如,产品的需求在迭代过程中频繁变动,就需要频繁 的更新 UML 图,这不仅增加了开发团队的负担,也可 能导致大量的工作成为无用功 。因此,过度的 UML 建 模会分散开发团队的注意力,使其无法集中精力在最核 心的任务上,如编写高质量的代码和解决问题上。
4.缺陷修改
软件开发的需求分析通常从功能性需求入手,并逐渐辐射到非功能性需求,在这些需求中,功能性需求是 需求分析的重点。本文以某高校问卷调查系统为例,利 用修改后的统一建模语言进行功能性需求分析,主要分 为微架构、功能分区、交互模型构建和简化 UML 图三 部分。
4.1 微架构功能分区
高校问卷调查系统主要是解决教师、学生在教学学 习中所存在的共性问题,是调查教学情况和学习情况的 有效途径。按照微架构功能划分为首页问卷管理、答卷 管理、用户管理四个部分,通过对系统进行调研,按照功 能分区,形成图一架构,如图 1 所示。按照微架构功能需 求分析得到功能性需求和非功能性需求,如表 1 所示。
4.2 用户交互模型构建
4.2.1 主要人物模型
主要人物模型用于描述本系统中绝大部分群体所具 有的特征,比如在高校问卷调查系统中,主要人物模型 为学生用户,如图 2 所示。
4.2.2 主要人物场景故事版
场景故事版主要用于描述用户在使用系统时所产生 的应用场景,并主要使用叙述的方式描述现实生活中的 交互场景,使用具体的例子以满足开发客户的要求。以 下是以学生为例产生的场景故事版。
以学生李明的问卷调查为例。首先,打开学校的问卷 调查系统,看到了 LOGO、系统名称以及简洁直观的简介 信息,然后点击登录入口,在弹出的对话框中输入用户名 和密码,成功登录之后,首页将直接呈现出来,此处列出 了若干最新发布的问卷调查,每个问卷旁边都有一段简要 的描述信息,点击进入了一个其中题为“关于校园素质教 育的问卷调查”,根据题型顺序作答,时间大约为 15min, 完成后点击提交按钮,将出现“您的答案已提交成功! 谢谢您的参与”。待确认反馈无误后,返回首页,再准 备参与其他的问卷,或是日后再访问此系统。
4.2.3 次要人物模型
次要人物模型主要描述在使用本系统中,辅助主要人物模型的群体,在本问卷调查系统中,次要人物模型 为系统管理员,如图 3 所示。
4.2.4 次要人物场景故事版
以下为次要人物模型系统管理员的场景故事版。
以系统管理员李华为例。首先, 打开学校的问卷调 查系统,看到了 LOGO、系统名称以及简洁直观的简 介信息,然后点击登录入口,在弹出的对话框中输入用 户名和密码,成功登录之后,进入问卷管理界面,可以 看到列出的所有的问卷信息,包括问卷名称、创建时间 和状态等。在此处会发现有一个新录入的问卷需要被发 布,点击该问卷,可进入问卷编辑界面,审阅所有问题 并确认无误后,点击发布,可使得该问卷被所有用户看 到并开始对此问卷进行答题,同时,此处还会发现一个 已经结束的问卷,对其做出关闭操作,使其不再对外可 见。接下来,管理员将前往答卷管理界面,此处可以看 到每个已发布问卷的答卷汇总情况,包括已参与人数、 答卷率等,选择其中一个填空题的统计数据进行汇报, 先查看其相关数据,再使用导出功能将数据保存到本 地,准备做进一步的分析。最后,管理员进入用户管理 界面,可以看到一些用户反馈密码丢失并需要找回的问 题,此问题可通过用户信息,帮助其恢复账户。另外, 还可以看到一些新注册的用户,可根据这些用户的身份,为其配置相应的权限。
4.3 简化 UML 图
微架构以及交互模型建模主要用于给提供软件产品 需求的客户阅读,对于具有专业能力的开发团队和产品 经理,用例分析阶段则需要采用另一种建模方案对用例 进行精确化的描述,将以用户视角描述的需求模型转换 为以开发团队视角描述的分析模型,从而保证设计开发 的准确性 [6],最终形成用例图,如图 4 所示。
在这个关系中,如图 4 和图 5 所示给出了基于顶 层设计的用例图以及时序交互图,在用力图中摒弃掉了 原有的细碎复杂的用力现象,转而使用了整体化的分层 次的用例。自顶向下的设计系统,在高校问卷调查系统 中,系统管理员处于用力的顶层,负责各方面的管理教 师用户和学生用户处于用例的底层。
在建立的需求分析模型中,目前所有识别出来的类 都是对静态描述的概述。然而,为了验证这些识别出的 类是否满足用例实现的目标,应当分析由它们所生成的 对象的动态行为。UML 时序图可以帮助我们描述对象 之间的交互行为,展示如何通过用例实现来达成用例目 标。以添加和查询问卷为例,通过时序图模型,开发人 员能够清楚地理解业务各个对象间的相互作用和信息传 递过程。形成时序图如图 5 所示。
至此, 一个完整的需求分析模型已经形成,包含了 系统用例以及相关用例实现的交互分析,并以可视化方 法记录在模型中。接下来,需求分析人员将基于系统用 户的目标、项目的范围和需求模型,去进行用例的详细描述。他们还需要结合非功能性需求、限制条件以及相 关外部接口到需求文档中。最后,需求文档必须经过评 审处理,以保证开始架构设计时需求是完整且一致的,减少后期开发风险。
5.
结论
需求分析是软件项目开发中的基础和关键,业务人 员需要针对提出需求的客户和开发团队给出不同的需求 分析说明类型图。在本文中,首先对比了软件开发的 多方面变革,同时给出了在变革条件下传统 UML 的缺 陷,并以高校问卷调查系统为例,详细阐述了在面向对 象思想下对于统一建模语言的缺陷和改进方法。该改进 方法能够十分有效地保证需求提出的客户和软件开发团 队之间产生有效高效的沟通,开发出符合规范性的软件 产品,在规定时间内并符合预算的条件下,完成软件项 目的开发、评审和上线。
在诸多软件开发实践中,在提高软件项目的质量、 降低开发风险、处理更加复杂的功能需求、减少代码的 重复度以及减少需求的更改等关键问题上减少修正,修正后的统一建模语言是行之有效的。
参考文献
[1] 吴政.软件开发过程中的需求分析探讨[J].电脑知识与技术, 2008.4(32):1125-1128.
[2] 袁涛,孔蕾蕾.统一建模语言UML(2版)[M].北京:清华大学出 版社,2014.
[3] WIEGERS K,BEATTY J.软件需求(3版)[M].李忠利,译.北 京:清华大学出版社,2016.
[4] Stephen R Schach.软件工程面向对象和传统的方法[M]. 邓迎春,韩松,等译.北京:机械工业出版社,2009.
[5] MACIASZEK L A.需求分析与系统设计[M].马素霞,王素 琴,谢萍,等译.北京:机械工业出版社,2009.
[6] 谭火彬.UML 2面向对象分析与设计(2版)[M].北京:清华大 学出版社,2019.
关注SCI论文创作发表，寻求SCI论文修改润色、SCI论文代发表等服务支撑，请锁定SCI论文网！
文章出自SCI论文网转载请注明出处：https://www.lunwensci.com/jisuanjilunwen/74210.html
