一、 关于需求分析与建模的读书心得

1) 我对需求分析与建模的认识与建议

1. 需求问题是当前软件开发面临的主要问题

随着计算机在日常工作中的普及，软件开发行业作为其必不可少的组成部分，被人们所认可。在我国，软件行业日渐成熟，小作坊式的开发形式，已经不能满足我国对于软件规范化、实用性的要求，软件开发流程化及各个职能部门工作的有效划分和正确协作，是现在软件行业面临的一个较大的问题。软件需求分析是软件开发的出发点，为设计起到指导性作用，所以需求分析在软件行业及开发流程中起着非常重要的作用。
“需求分析”,就是对需要解决的问题进行详细分析,弄清楚需要解决的问题。开发人员需要了解顾客的需求,然后体现在软件中。如果说软件开发过程中,开发人员需要了解自己做什么,顾客需要告诉开发人员自己需要什么,而需求分析就是连接开发人员和顾客之间的重要纽带。只有真正理解顾客的需求,才能设计出顾客所需要的软件。

2. 需求问题具体原因分析

（1） 非技术性和社会性因素重视不足：应用型软件的模拟特性使得需求处理具有很突出的特性，相对于软件开发的其他阶段而言，需求处理阶段设计更多的非技术性和社会性因素，并且其所受的影响也远远高于其他阶段。
（2） 传统需求分析方法的缺陷：传统的需求分析方法，如结构化分析和面向对象分析，都是从设计领域转入分析领域的。虽然它们在设计阶段取得了很大的成功，但他们并不非常适合于需求阶段的技术处理需要，因此它们在需求处理中的应用具有一定的先天缺陷。
（3） 软件规模的日益扩大：20世纪90年代之后大量出现的以“企业”为中心的软件反映了软件规模日益扩大的发展趋势，这一方面提高了需求中非技术性和社会性因素的影响比重，另一方面也进一步放大了传统技术在需求处理阶段的不适应性。
（4） 需求问题的高代价性：需求处理是软件工程的起始阶段，设计、实现等后续阶段的正确性都以它的正确性为前提；如果在需求处理过程中有错误未能解决，则其后的所有阶段都会受到影响，因此与需求有关的错误修复代价较高，需求问题对软件成败的影响较大。

3. 需求工程的重要性

需求工程的重要性主要表现在：增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解， 增强了项目涉众对需求(尤其是复杂需求)的掌握；增进了项目涉众之间的交流，减少了可能的误解和交流偏差；需求管理能够更加有效地处理需求变更，提高了生产效率；需求跟踪信息能够更加准确地反映项目的进展情况，以便进行更好的项目决策；使得项目涉众认识到需求在项目工作中的重要性，使得需求的作用得到重视和有效发挥。良好的需求分析和管理工作，才能把系统的功能描述和性能指标转化为具体的软件需求规格说明书，成为系统建设的依据和基础。

4. 需求工程的复杂性

需求工程的复杂性体现在以下几个方面：1、处理范围广泛：需求工程连接现实世界和计算机世界。2、涉及诸多参与方：常见的参与方包括客户、用户、领域专家、需求工程师、软件开发者和系统维护者等。3、处理内容多样：需求工程处理的知识内容多种多样，既有用户的功能需求和非功能需求，又有软件将来所处的环境及其约束，环境由人、设备和其他软件组成。4、处理活动互相交织：需求工程包括需求获取、需求分析、需求规格说明和需求验证等四个需求开发活动，他们互相衔接、顺序处理；需求开发的各项活动虽然在理论上具有顺序处理的特性，但在实际执行过程中往往是迭代和互相交织的。5、处理结果要求苛刻：作为需求处理结果的需求规格说明要满足正确性、完整性和一致性等苛刻要求。

2) 我对需求分析与建模的读书心得

1. 我对需求分析与建模的读书心得

我对需求分析与建模的读书心得是这门课程在上课时因为有太多的理论知识要讲解，所以相对于其他的课大部分学生会觉得这门课程比较无趣，再加上需要同学们时不时地画上几个UML图，这门课程恐怕是同学们最不喜欢的课程了。
虽然这门课程确实比其他实机操作课无聊，可是需求分析与建模这门课程却是我们必须要学而且必须要学好的一门课，我们软件工程系的学生以后肯定是参与设计软件或是系统的，所以我们是没办法躲过需求分析与建模的，只有我们掌握了有关的知识，我们才有可能做到项目总监或是更高的职位，时代不同，只会敲代码的人除非是技术好到可以开发自己的独特的有创造性的系统或是程序，不然升职实在是太慢了，必须要掌握一些旁人难以领悟的知识，我们才能更好地就业。
程序开发语言不断地再创新，总有一天我们的技术水平会慢慢地落后比我们更年轻的程序员，但是掌握了需求分析的知识之后，我们可以轻松很多，开发语言更新的速度总要比需求分析的技术更新来得快。
需求获取、需求规格、需求验证与确认、需求管理这些知识很难过时，是需求分析的全部步骤，也是一个软件开发的重中之重。
从20世纪60年代末期软件工程产生起， 需求分析就一直是软件开发的重要主题；20世纪90年代的调查状况表明，单纯的需求分析已经不能很好的解决软件生产中的“需求” 问题；应用型软件的模拟性和一系列的技术原因表明软件生产需要进行一个比需求分析更加复杂和完整的需求工程；需求工程是软件工程当中一项重要和复杂的活动， 需求工程需要具备一定的知识和技能才可以很好的执行需求工程活动。软件需求是决定软件开发的一个关键因素，包括业务需求、用户需求、功能需求和非功能需求等不同层次。需求工程实现对软件需求的开发和管理，其中需求开发的主要任务是需求获取、需求分析、编写需求规格说明和需求验证，而需求管理则针对需求开发的结果进行变更控制、版本控制和需求跟踪。需求文档在软件开发过程中起着重要的作用，需要采用适当的方法保证其一致性、完备性和无二义性，评审和验证是发现需求错误的有效手段。总而言之，对于软件工程的学生来说，需求分析是无法避免而且相当重要的开发软件的前提步骤，我们应该有效地完成需求分析，这一切都需要我们软件工程的学生认真学习、对待需求工程这门课程。

二、 关键词查找结合小组项目的内容

1) 第一类关键词

1、活动图(Activity diagram)认知说明：
活动图本质上是一种流程图，它描述活动的序列，即系统从一个活动到另一个活动的控制流。用于描述用例，描述类的操作，另外，可以用来描述算法（单独使用）。

高校人事管理系统 活动图分析：
在我们小组的人事管理系统中，活动图可以理解成类似上图的例子，员工输入账号密码登录人事管理系统，然后开始打卡，打卡成功后事件结束，完成活动图。

2) 第二类关键词

11、包含关系(Include Relationship)认知说明：
包含关系将基本用例连接到包含用例。包含用例总是抽象的。它描述了插入到执行基本用例的用例实例中的行为段。基本用例控制着与包含的关系，并且可以依赖于执行包含的结果，但是基本用例和包含都不能访问彼此的属性。从这个意义上说，包含是封装的，并且表示可以在不同的基本用例中重用的行为。

高校人事管理系统 包含关系分析：
在高校人事管理系统中，基本用例是多样化的，这意味着包含关系也是多样化的，基本用例如查看信息等都控制着与包含的关系，依赖于执行包含的结果，但是包含不能访问基本用例的关系。

12、过渡(Transitions)认知说明：
过渡是源顶点和目标顶点之间的有向关系。它可能是复合转换的一部分，复合转换将状态机从一种状态配置带到另一种状态配置，表示状态机对特定类型事件发生的完整响应。从一个状态到下一个状态的过渡由事件触发。事件由一个名称和一系列可能的参数组成。一个状态可以对事件设置必须满足的条件，这样这个状态就可以被这个事件接受。这些条件可以独立于特殊事件。

高校人事管理系统 过渡分析：
在高校人事管理系统中，过渡是从一个事件到另一个事件之间的状态，同时它也有可能是从一个状态到另一个状态的转换过程，即它是对人事管理系统从打卡事件到修改个人信息的转换过程的描述，也是对打卡事件从提交打卡信息状态到打卡成功状态的转换过程的描述；过渡也可以是一个关系，描述提交打卡信息状态与打卡成功状态的关系，但是过渡的发生必须具备一定的条件，而且这些条件独立于特殊事件。
2) 第二类关键词
11、包含关系(Include Relationship)认知说明：
包含关系将基本用例连接到包含用例。包含用例总是抽象的。它描述了插入到执行基本用例的用例实例中的行为段。基本用例控制着与包含的关系，并且可以依赖于执行包含的结果，但是基本用例和包含都不能访问彼此的属性。从这个意义上说，包含是封装的，并且表示可以在不同的基本用例中重用的行为。

高校人事管理系统 包含关系分析：
在高校人事管理系统中，基本用例是多样化的，这意味着包含关系也是多样化的，基本用例如查看信息等都控制着与包含的关系，依赖于执行包含的结果，但是包含不能访问基本用例的关系。

12、过渡(Transitions)认知说明：
过渡是源顶点和目标顶点之间的有向关系。它可能是复合转换的一部分，复合转换将状态机从一种状态配置带到另一种状态配置，表示状态机对特定类型事件发生的完整响应。从一个状态到下一个状态的过渡由事件触发。事件由一个名称和一系列可能的参数组成。一个状态可以对事件设置必须满足的条件，这样这个状态就可以被这个事件接受。这些条件可以独立于特殊事件。

高校人事管理系统 过渡分析：
在高校人事管理系统中，过渡是从一个事件到另一个事件之间的状态，同时它也有可能是从一个状态到另一个状态的转换过程，即它是对人事管理系统从打卡事件到修改个人信息的转换过程的描述，也是对打卡事件从提交打卡信息状态到打卡成功状态的转换过程的描述；过渡也可以是一个关系，描述提交打卡信息状态与打卡成功状态的关系，但是过渡的发生必须具备一定的条件，而且这些条件独立于特殊事件。

3) 第三类关键词

21、软件需求文件(Software requirements documentation)认知说明：
软件开发是一个令人兴奋的创造性解决问题、设计和工程的过程。但是在闪亮的应用程序和精致的网页之下，隐藏着一个不那么性感但非常重要的脚手架，它让好的软件成果成为可能:文档。文档确保团队和个人涉众在产品或软件应用程序的目标、范围、约束和功能需求方面意见一致。
不幸的是，创建和记录这些需求的过程可能是乏味、混乱和混乱的。软件需求文档可能很快变成冗长、笨拙、文本量大的文档，使它们特别容易出错、不一致和被曲解。正因为如此，编写和使用这些文档可能会很耗时，并导致代价高昂的(也是可以避免的)设计错误。

高校人事管理系统 软件需求文件分析：
在高校人事管理系统中，软件需求文件就是对用户与领导等等涉众的需求的分析，在编写软件需求文件时主要考虑关键涉众即教职工、领导的需求，软件需求文件必须在项目开始的第一步就完成。

22、需求管理(Requirements management)认知说明：
需求管理是收集、分析、提炼产品需求并对其进行优先级排序，然后规划其交付的过程。需求管理的目的是确保组织验证并满足其顾客以及外部和内部利益相关者的需求。需求管理包括项目团队成员和利益相关者之间的沟通，以及在整个项目过程中对需求变化的调整。为了防止一类需求覆盖另一类需求，开发团队成员之间的持续沟通是至关重要的。需求管理不会随着产品发布而结束。从那时起，关于应用程序可接受性的数据被收集起来，并输入到下一代或下一个版本的调查阶段。这样，这个过程就会再次开始了。

高校人事管理系统 需求管理分析：
在高校人事管理系统中，需求管理也包括在软件需求文件里，是在对项目关键涉众的需求分析完成后再进行进一步的分析管理，结合领导（利益相关者）与开发团队的利益，对软件需求文件的修改与完善，这一系列操作就是高校人事系统的需求管理。

23、非功能性需求(Non-functional requirements)认知说明：
非功能需求定义了系统属性，如安全性、可靠性、性能、可维护性、可扩展性和可用性。它们在不同的积压工作中作为系统设计的约束或限制。也称为系统质量，非功能性需求和功能性史诗、功能、特性和故事一样重要。它们确保了整个系统的可用性和有效性。未能满足其中任何一项都可能导致系统无法满足内部业务、用户或市场需求，或者无法满足监管机构或标准机构强加的强制性要求。在某些情况下，不合规会导致重大的法律问题(隐私、安全、安保等)。与功能需求不同，非功能需求是持久的质量和约束，通常在每次迭代、程序增量或发布时作为完成定义的一部分被重新考虑。非功能需求影响所有的积压工作:团队、项目、解决方案和投资组合。国家森林资源的适当定义和实施至关重要。过度指定它们，解决方案可能成本太高而不可行；对他们的详细说明不够或表现不佳，系统将无法满足其预期用途。探索、定义和实现非功能需求报告的适应性和增量方法是敏捷团队的一项重要技能。

高校人事管理系统 非功能性需求分析：
在高校人事管理系统中，非功能性需求可以简单理解为系统的质量需求，主要包含了安全性、可靠性、性能、可维护性、可扩展性和可用性等；这些都是非功能性需求，但是用户在使用时最考虑稳定性与可用性，不同于功能需求，非功能性大多都是隐性的。

24、外显性质(Emergent properties)认知说明：
外显性质是各种系统组件一起工作的结果，而不是任何单个组件的属性。换句话说，它是一个复杂系统或系统部件的集合所具有的属性，但却是单个部件所不具备的。该术语用于系统理论、科学、哲学，甚至是创造性的媒介，它概括了“大于其各部分之和”的习语。因为在更宏观的分析层次上可以看到涌现的特性，所以只检查系统的单个部分将会阻止人们看到涌现的特性。涌现属性的例子包括生化系统、大脑和蚁群。让我们仔细看看一些涌现属性的例子，并讨论该属性如何只在正确的分析级别上显示自己。

高校人事管理系统 外显性质分析：
在高校人事管理系统中，外显性质是一个复杂系统或系统部件的集合所具有的属性，但却是单个部件所不具备的，它属于一整个高校人事管理系统，是登录子系统、功能子系统（打卡子系统、请假子系统）、修改信息子系统等等共同工作时的结果。

25、项目关系人(Project stakeholders)认知说明：
确定利益相关者是一项主要任务，因为项目启动、规划和执行阶段的所有重要决策都由这些利益相关者做出。五个主要的项目涉众是项目经理、项目团队、职能管理层、发起人和客户。从更大的意义上说，任何参与项目或受项目结果影响的人都是利益相关者。每个利益相关者都有重要的贡献，所有利益相关者的期望都需要得到满足。不同的人对项目的贡献是确定利益相关者的主要标准。

高校人事管理系统 项目关系人分析：
在高校人事管理系统中，项目关系人可以理解为涉众，主要有开发团队、教职工、领导、外界力量（专家、行业趋势、政府等）；其中，关键涉众有教职工、领导。

26、需求抽取技术(Requirements elicitation technique)认知说明：
实际需求获取是对任何软件测试项目的完成至关重要的一个环节。令人震惊的是，这是一个经常被许多业务分析师忽略的过程。在时间和支出计划方面，这种疏忽对项目来说可能是昂贵的，然而，更重要的是，这可能会导致分散的需求，或者更严重的是，导致项目失败。有很多需求获取技术，而且任何一种技术都可靠地为你服务是可疑的。尽管有些人可能只提倡一种启发方法——但人们普遍认为，一种技术不可能对所有项目都合理。

高校人事管理系统 需求抽取技术分析：
在高校人事管理系统中，需求抽取技术跟需求管理一样，也是在编写软件需求文件时用到的一个技术或步骤，是在编写软件需求文件时不可或缺的一步。

27、需求确认(Requirements validation)认知说明：
需求验证是检查为开发定义的需求，定义客户真正想要的系统的过程。为了检查与需求相关的问题，我们执行需求验证。我们通常在开发的初始阶段使用需求验证来检查错误，因为在开发过程的后期检测到错误时，可能会增加过多的返工。在需求验证过程中，我们执行不同类型的测试来检查软件需求规范中提到的需求，这些检查包括:
完整性检查
一致性检查
有效性检查
真实性检查
歧义检查
可验证性
需求验证的输出是问题列表和对检测到的问题的一致行动。问题列表表明在需求验证过程中检测到的问题。商定措施的列表说明了应采取的纠正措施，以解决检测到的问题。

高校人事管理系统 需求确认分析：
在高校人事管理系统中，需求确认在需求抽取之后进行，是在编写软件需求文件时用到的一个技术或步骤，是在编写软件需求文件时不可或缺的一步。

28、需求工程程序(Requirement engineering processes)认知说明：
需求工程是定义、记录和维护需求的过程。这是一个收集和定义系统提供的服务的过程。需求工程流程包括以下主要活动:
需求获取
需求规格
需求验证和确认
需求管理

高校人事管理系统 需求工程程序分析：
在高校人事管理系统中，需求工程程序是软件需求文件在编写时使用的一个总的手段，办函了需求识别、需求抽取、需求验证与确认、需求管理等步骤。

29、需求规格制订(Requirements specification)认知说明：
在软件开发中，需求规格说明是一系列过程的结果，这些过程旨在收集和记录描述系统或应用程序行为的信息。无论是网站、移动应用程序还是任何其他类型的系统，您都应该在实现阶段开始之前编写一个需求规范。如果用户和开发者是不同的两方，这一点尤其重要。
需求规格说明的目的是为相关方(如用户和开发人员)提供一个系统应该是什么样子的共同画面。此外，需求规格说明在实现阶段和稍后的测试阶段都非常重要(在测试阶段，功能与预定义的需求进行比较)。需要注意的是，规范永远不能取代相关方之间良好的持续沟通。
此外，在某些情况下，需求规格也可以作为招标文件，包括交付时间和开发商方的报价。由于几个原因，在开发过程中更新文档很重要。客户端可能会出现新的功能需求，开发人员可能会出现可能的延迟/实施问题。

高校人事管理系统 需求规格制订分析：
在高校人事管理系统中，需求规格说明是一系列过程的结果，这些过程旨在收集和记录描述系统或应用程序行为的信息。需求规格也可以作为招标文件，包括交付时间和开发商方的报价。需求规格说明在实现阶段和稍后的测试阶段都非常重要(在测试阶段，功能与预定义的需求进行比较)。

30、统一塑模语言(Unified modeling language)认知说明：
UML，统一建模语言的简称，是一种标准化的建模语言，由一组集成的图组成，旨在帮助系统和软件开发人员指定、可视化、构建和记录软件系统的工件，以及业务建模和其他非软件系统。UML代表了在大型复杂系统建模中被证明是成功的最佳工程实践的集合。UML是开发面向对象软件和软件开发过程中非常重要的一部分。统一建模语言主要使用图形符号来表达软件项目的设计。使用统一建模语言帮助项目团队进行交流，探索潜在的设计，并验证软件的架构设计。在本文中，我们将向您详细介绍什么是统一建模语言，统一建模语言的历史和每种统一建模语言图表类型的描述，以及统一建模语言的例子。

高校人事管理系统 统一塑模语言分析：
在高校人事管理系统中，统一塑模语言帮助系统和软件开发人员指定、可视化、构建和记录软件系统的工件，以及业务建模和其他非软件系统。统一建模语言主要使用图形符号来表达软件项目的设计。

4) 第四类关键词

31、系统塑模(System modeling)认知说明：
控制软件设计过程的第一步是开发被控制系统的适当数学模型。这些模型可以来自物理定律或实验数据。在这一节中，我们介绍了动态系统的状态空间和传递函数表示。

高校人事管理系统 分析：
在高校人事管理系统中，系统建模在确定系统需求之后进行，给后面的工作提供一个大致的开发架构。

32、模型驱动工程(Model-driven engineering)认知说明：
模型驱动工程(MDE)是一个迭代和增量的软件开发过程。支持按照MDE范式开发的软件系统的分析和验证，要求在以更优化的方式执行这些关键任务时采用增量方法。
通信状态机是MDE工具中用于建模和描述分布式、并发和实时反应系统(例如，汽车和航空电子系统)行为的各种形式之一。对这种系统的整体行为进行建模是以模块化的方式在不同的抽象层次上进行的(即，它首先对系统中各个对象的行为进行建模，然后对这些对象之间的交互进行建模)。同样，分析和验证已开发模型的正确性以确保其质量和完整性是在两个主要层面上进行的。层内用于分析独立于其他模型的单个模型的正确性，而层间用于分析相互通信的模型的整体互操作性。

高校人事管理系统 模型驱动工程分析：
在高校人事管理系统中，模型驱动工程(MDE)在电信行业有着悠久的历史，因为这些公司是第一批面临创建大型、分布式、可靠系统复杂性的公司。

33、案例模型(Use case modeling)认知说明：
用例模型描述了新系统的建议功能。用例代表用户(人或机器)和系统之间交互的离散单元。这种交互是一个有意义的工作单元，例如创建帐户或查看帐户详细信息。
每个用例描述了要在建议的系统中构建的功能，它可以包括另一个用例的功能，或者用它自己的行为扩展另一个用例。
用例描述通常包括:
描述用例的一般注释和注释。
需求——用例必须向最终用户提供的事物的正式功能需求，例如<更新订单的能力>。这些对应于结构化方法中发现的功能规范，并形成一个契约，用例执行一些动作或为系统提供一些价值。
约束——用例运行的正式规则和限制，定义什么能做什么不能做。其中包括:
运行用例之前必须已经发生或已经存在的前提条件；例如，<创建订单>必须在<修改订单>之前
一旦用例完成，后条件必须为真；例如，<订单已修改且一致>
在用例运行的整个过程中必须始终为真的不变量；例如，订单必须始终有一个客户编号。
场景——对执行用例所采取的步骤的正式的、连续的描述，或者在用例实例中发生的事件流。这些可以包括多个场景，以适应特殊情况和替代处理路径。这些通常以文本形式创建，对应于序列图的文本表示。
场景图——描述工作流程的序列图；类似于场景，但以图形方式描绘。
附加属性，如实现阶段、版本号、复杂度等级、原型和状态。

高校人事管理系统 案例模型分析：
在高校人事管理系统中，用例模型中每个用例描述了要在建议的系统中构建的功能，它可以包括另一个用例的功能，或者用它自己的行为扩展另一个用例。

34、行为模型(Behavioral models)认知说明：
行为模型的概念：所需行为或所需行为模式的详细概念。这种概念化包括根据观察到的公开行为对心理障碍的系统描述。

高校人事管理系统 行为模型分析：
在高校人事管理系统中，行为模型并未被建立。

35、实时系统(Real-time systems)认知说明：
实时系统出现在过程控制和自动化中，它们越来越多地涉及与安全相关的应用。实时操作模式在德国工业标准DIN 44300 (1985)中被定义为计算机系统的操作模式，其中用于处理来自外部的数据的程序是永久准备好的，使得它们的结果将在预定的时间周期内可用；根据不同的应用，数据的到达时间可以随机分布或先验地确定。因此，实时计算机控制系统总是嵌入在更大的环境中，它们必须跟上环境的动态变化。因此，它们通常被视为嵌入式系统的同义词。
实时操作的特点是时间维度的明确参与，体现在基本的及时性要求上，即使在极端负载条件下，实时系统也必须满足这一要求。根据外部流程的要求，必须按时进行数据采集、评估和适当的反应。处理速度并不是决定性的，而是在预定义的和可预测的时间范围内的及时反应，尽管目前的技术水平还远远不能保证这样的范围。因此，实时系统的特点是，它们的功能正确性不仅取决于处理结果，还取决于这些结果可用的时刻。特别是在错误情况下，用户希望系统行为是可预测的，例如性能下降。只有完全确定性的系统行为才能最终为安全关键应用的计算机提供有效的安全许可。因此，系统行为的可预测性对于实时操作模式至关重要。它补充了时间性需求，因为后者只有在系统行为在时间和外部事件反应方面是精确可预测的情况下才能得到满足。

高校人事管理系统 实时系统分析：
在高校人事管理系统中，实时系统是时间关键的，它们的实现效率比其他系统更重要。效率可以根据处理器周期、内存或功耗进行分类。这种约束可能驱动从处理器的选择到编程语言的选择的一切。

36、平台独立模型(Platform independent model)认知说明：
平台独立模型侧重于高级业务逻辑，不考虑系统实现技术的特点，不包含对底层技术平台的引用的模型。

高校人事管理系统 平台独立模型分析：
在高校人事管理系统中，平台独立模型未被建立。

37、计算独立模型(Computation independent model)认知说明：
CIM的一个候选是状态图，它将所有用例的状态图组合成宏或子状态。(宏观状态是包含微观状态和跃迁的状态。)

高校人事管理系统 计算独立模型分析：
在高校人事管理系统中，计算独立模型未被建立。

38、平台特定模型(Platform specific model)认知说明：
以特定于特定实现平台的方式定义功能的软件或系统模型。

高校人事管理系统 平台特定模型分析：
在高校人事管理系统中，平台特定模型未被建立。

39、四方块图

40、需求图

1、一级需求层次结构模式允许在层次结构中可视化需求，允许将复杂的需求分解为更细粒度的需求，直至单个级别。
2、当需求描述一个完整的系统时，它通常是在系统描述的早期创建的；但是它可以在任何时候创建，特别是当需求描述一个子系统或系统的一部分时。
3、高校人事管理系统主要的系统需求有服务需求、性能需求、工资管理、请假管理、用户管理、职位管理。

5) 第五类关键词

41、软件架构设计(Software architecture design)
软件体系结构通常是指软件系统的更大结构，它涉及多个软件流程如何协作执行任务。软件设计是指较小的结构，它处理单个软件过程的内部设计。在本教程结束时，读者将对软件体系结构和设计概念有深入的了解，并可以为给定的软件项目选择和遵循正确的模型。
系统的体系结构描述了其主要组件，它们之间的关系（结构）以及它们之间如何交互。软件体系结构和设计包括几个促成因素，例如业务战略，质量属性，人员动态，设计和IT环境。

体系结构是系统的蓝图。它提供了一种抽象方法来管理系统复杂性，并在组件之间建立通信和协调机制。
• 它定义了一种结构化的解决方案，可以满足所有技术和运营要求，同时优化性能和安全性等通用质量属性。
• 此外，它涉及与软件开发有关的一组与组织有关的重要决策，并且这些决策中的每一个都会对最终产品的质量，可维护性，性能和整体成功产生重大影响。这些决定包括-
o 选择组成系统的结构元素及其界面。
o 在这些元素之间的协作中指定的行为。
o 将这些结构和行为元素组成大型子系统。
o 体系结构决策符合业务目标。
o 建筑风格指导组织。

软件设计提供了一个设计计划，该计划描述了系统的元素，它们如何适合以及如何共同满足系统的需求。制定设计计划的目标如下-
• 与系统需求进行谈判，并与客户，市场营销和管理人员建立期望。
• 在开发过程中充当蓝图。
• 指导实施任务，包括详细的设计，编码，集成和测试。
在详细设计，编码，集成和测试之前，在领域分析，需求分析和风险分析之后。
该体系结构的主要目标是确定影响应用程序结构的需求。布局合理的体系结构可减少与构建技术解决方案相关的业务风险，并在业务和技术要求之间架起一座桥梁。

42、架构设计程序(Architectural design processes)
架构设计是人们对一个结构内的元素及元素间关系的一种主观映射的产物。架构设计是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。

架构师是软件行业中一种新兴职业，工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。架构设计是软件设计过程的早期阶段，它把需求分析和设计流程连接在一起。架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。他必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个架构师工作的好坏决定了整个软件开发项目的成败。
所谓架构师通俗的说就是设计师、画图员、结构设计者，这些定义范畴主要用在建筑学上很容易理解。小时候到河中玩耍，经常干的事就是造桥，步骤如下：1、在沙滩上画图；2、选择形状好看、大小适合的石头；3、搭建拱桥。其中我们挑出来画图的那位光PP小孩就是传说中的“架构师”了。
在软件工程中，架构师的作用在于三方面：1、行业应用架构，行业架构师往往是行业专家，了解行业应用需求，其架构行为主要是将需求进行合理分析布局到应用模型中去，偏向于应用功能布局；2、应用系统技术体系架构，技术架构师往往是技术高手中的高手，掌握各类技术体系结构、掌握应用设计模式，其架构行为考虑软件系统的高效性、复用性、安全性、可维护性、灵活性、跨平台性等；3、规范架构师是通过多年磨砺或常年苦思顿悟后把某一类架构抽象成一套架构规范，当然也有专门研究规范而培养的规范架构师。他们的产物往往也分为应用规范和技术规范两类。

43、异动处理系统(Transaction processing)
事务处理是一种计算类型，通常由大型服务器计算机执行，支持交互式应用程序。在事务处理中，工作分为单个的，不可分割的操作，称为事务。相反，批处理是一种计算方式，其中一个或多个程序处理一系列记录（一批），而用户或操作员几乎没有采取任何行动。
我们的高校人事管理系统也将采用事务处理系统，当用户在使用系统时，出现异常操作或者突然断电等突发情况时，保护用户的数据。
常见的异常：

事务处理系统通过使应用程序免受事务管理细节的影响，使应用程序程序员可以专注于编写支持业务的代码：
1.它管理事务的并发处理。
2.它可以共享数据。
3.它确保数据的完整性。
4.它管理事务执行的优先级。
当事务开始处理时，CICS运行与该事务关联的程序。该程序可以在事务处理过程中将控制权转移到其他程序，从而可以组装由许多CICS程序组成的模块化应用程序。
在CICS系统中，任何时候，事务的许多实例都可以同时运行。正在运行的事务的单个实例称为任务。
在任务运行期间，它可以独占使用（或持有锁定）它更改的每个数据资源，从而确保事务的隔离属性。需要访问资源的其他任务必须等待，直到释放锁定。为了确保事务处理系统的整体响应能力，请设计CICS应用程序，以使它们在最短的时间内持有锁。例如，您可以将事务设计为短暂的，因为CICS在任务结束时释放锁。
• 事务的ACID属性
在事务处理的上下文中，缩写ACID指事务的四个关键属性：原子性，一致性，隔离性和持久性。
• 提交和回滚
为了确保事务的ACID属性，在事务过程中对数据所做的任何更改都必须提交或回滚。
• 工作单元
事务的一致性属性可确保数据在事务开始和结束时处于一致状态。在CICS中，由两个一致性点之间的事务执行的可恢复操作序列被称为工作单元。
• 分布式事务处理概述
这些主题描述了CICS分布式事务处理（DTP）的基本概念，以及在设计DTP应用程序时必须考虑的内容。
• 商业交易
CICS交易支持的商业交易通常涉及许多动作，这些动作有时会持续几天或几周。通过使用CICS商业交易服务（BTS），您可以控制复杂商业交易的执行。
• 恢复和重新启动
CICS连续记录有关区域状态以及该区域中每个工作单元状态的信息。重新启动区域时，将保留并使用此信息，从而使CICS能够重新启动而不会丢失数据完整性。

44、架构设计决策(Architectural design decisions)
在大多数体系结构开发过程中，在不同的体系结构域中做出不同的决定。架构师可能会在概念体系结构中做出不同的决定，例如选择特定的组件，并遵循特定的体系结构模式。
但是，诸如开发人员，业务用户甚至其他架构师之类的利益相关者没有时间去通过不同的架构视图来理解架构的含义。例如，业务用户希望清楚地了解将要发生的更改，并确保体系结构满足其业务需求。其他领域的架构师希望对架构的关键方面有一个清晰的了解，包括架构师在构想阶段考虑的基本原理和替代方案。
作为一名架构师，您可能会面临不同的挑战或业务需求，这些挑战或业务需求可以通过不同的选项来实现，或者您需要选择特定的模式或样式。作为一种决定方式，您将必须经历一个过程并进行长时间讨论，以了解为什么需要做出这些决定并提出建议，而不是考虑其他决定。
那么，什么是架构决策？对软件体系结构的体系结构增减集，基本原理以及设计规则，设计约束和附加要求（部分实现对给定体系结构的一个或多个要求）的描述-软件体系结构作为一组Anton Jansen和Jan Bosch撰写的《建筑设计决策》论文，称为架构策略。
为什么架构决策很重要？通过交流架构变更和决策，我们可以将其视为一种思考方式，以总结我们为何需要此决策以及为什么决定进行此变更并为此选择此选项，并且还描述了此变更的影响已根据决定进行更改。这对于其他利益相关者（例如业务用户，域架构师或开发人员）很重要。结束开放的问题和漫长的讨论循环，在体系结构开发过程中，我们可能会进行大量讨论和集思广益会议，实际上，我们需要与其他利益相关者进行交流。在整个过程中，不同领域的其他利益相关者甚至新的建筑师将开始建议或讨论可能不符合所做出决定的另一种选择。在这方面，记录体系结构决策将消除该周期，并将决策的依据传达给所有利益相关者，并使其保持历史性，以了解如何也受新更改的影响。当我们知道我们为什么要执行这些决策，与这些决策相关的关注点和业务需求是什么，以及这些决策的贡献者时，它将提供一种可追溯性的方式。架构治理，决策日志和记录用于跟踪这些决策以及它们如何符合我们遵循的标准。

45、分层式架构(Layered architecture)
SimArch是一种分层体系结构，通过从与执行环境有关的所有细节中删除开发人员，可以简化本地和分布式仿真系统的开发，该执行环境可以是常规的本地执行平台，也可以是分布式执行平台，例如基于HLA的平台。
下图为我们高校管理系统的分层架构图：

用户有领导、教师、后勤人员以及管理员。

在分层体系结构中，对象是使用构造块思路设计的。底层由执行低级，通常乏味的功能的对象组成。下一层具有较高的功能，并调用较低层中的对象。向上的每个连续层在功能上都更高。解释此分层的一种常见方式是“抽象了”细节，这意味着执行功能所需的一些繁琐细节仅通过将它们委派给较低级别的对象而对较高级别的对象隐藏了。在分层体系结构中，对象调用全部向下。这种架构是大多数高级语言（包括适用于Java等面向对象语言的应用程序编程接口（API）。

46、 MVC(the Model-View-Controller)
在模型-视图-控制器（MVC）是分开的应用程序分为三个主要逻辑组件的体系结构图案：该模型，视图和控制器。这些组件中的每个组件都是为处理应用程序的特定开发方面而构建的。MVC是创建可伸缩和可扩展项目的最常用的行业标准Web开发框架之一。
以下是MVC的组件：

模型：
模型组件对应于用户使用的所有与数据相关的逻辑。这可以表示在View和Controller组件之间传输的数据，也可以表示任何其他与业务逻辑相关的数据。例如，客户对象将从数据库中检索客户信息，对其进行处理并将其数据更新回数据库，或使用它来呈现数据。
视图：
View组件用于应用程序的所有UI逻辑。例如，“客户”视图将包括最终用户与之交互的所有UI组件，例如文本框，下拉菜单等。
控制器：
控制器充当Model和View组件之间的接口，以处理所有业务逻辑和传入请求，使用Model组件处理数据，并与View交互以呈现最终输出。例如，客户控制器将处理客户视图中的所有交互和输入，并使用客户模型更新数据库。使用同一控制器查看客户数据。

47、语言处理系统(Language processing system)
对于我们大多数人而言，言语表达似乎毫不费力。而且，这是一个多方面且复杂的过程，需要访问语言处理系统的不同组件。尽管单词的发音（即声道的发音运动模式）可能是终点，但该过程始于单词的概念化，从心理词典中选择其词汇表示形式和相应的声音属性以及映射这些语音表现形式进入发音计划和实施阶段。此外，说话者不仅会被动地发声，而且会持续地在瞬间进行监控，以根据听觉和体感同时适应短期或长期的输出。从产品本身收到的反馈。

尽管细节可能有所不同，但语音生产功能体系结构的当前模型通常会根据生产的不同阶段来识别语音生产的这些不同方面。这些阶段被认为在功能上是不同的并且按层次进行组织，在每个处理阶段都具有前馈和反馈机制（图55.1））。本章的目的是从神经心理学和神经生理学研究中检查语音生成过程的当前数据和模型。为此，我们首先提供从失语症文献中得出的简要历史观点，该文献已成为许多神经生理学研究的框架。然后，我们考虑概述的拟议生产阶段，首先回顾生产的语音阶段，然后是生产的语音/发音阶段，整合基于病变和神经生理学研究的结果。它们一起表明语音产生会募集一个包含语言网络的神经网络，包括时态，顶叶和额叶结构。

48、网站服务器(Web server)
Web服务器是使用HTTP （超文本传输协议）和其他协议来响应通过万维网发出的客户端请求的软件和硬件 。Web服务器的主要工作是通过存储，处理并将网页交付给用户来显示网站内容。除了HTTP，Web服务器还支持SMTP（简单邮件传输协议）和FTP（文件传输协议），用于电子邮件，文件传输和存储。
我们的高校人事管理系统采用tomcat服务器来部署。

Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，属于轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选。对于一个初学者来说，可以这样认为，当在一台机器上配置好Apache 服务器，可利用它响应HTML（标准通用标记语言下的一个应用）页面的访问请求。实际上Tomcat是Apache 服务器的扩展，但运行时它是独立运行的，所以当你运行tomcat 时，它实际上作为一个与Apache 独立的进程单独运行的。
Web服务器硬件连接到Internet，并允许与其他连接的设备交换数据，而Web服务器软件控制用户如何访问托管文件。Web服务器进程是客户端/服务器 模型的示例 。承载网站的所有计算机都必须具有Web服务器软件。
Web服务器用于Web托管或网站和基于Web的应用程序（或Web应用程序）的数据托管。
Web服务器如何工作？Web服务器软件可通过网站的域名进行访问，并确保将网站内容交付给发出请求的用户。软件方面还包括至少一个HTTP服务器的几个组件。HTTP服务器能够理解HTTP和URL。Web服务器作为硬件，是一台存储Web服务器软件和与网站相关的其他文件（例如 HTML 文档，图像和 JavaScript 文件）的计算机。当网络浏览器（例如Google Chrome或Firefox）需要在网络服务器上托管的文件时，浏览器将通过HTTP请求该文件。当Web服务器接收到请求时，HTTP服务器将接受该请求，查找内容并将其通过HTTP发送回浏览器。更具体地说，当浏览器从Web服务器请求页面时，该过程将遵循一系列步骤。首先，一个人将在网络浏览器的地址栏中指定一个URL。然后，Web浏览器将获取域名的IP地址-通过DNS（域名系统）翻译URL或在其缓存中搜索。这会将浏览器带到Web服务器。然后，浏览器将通过HTTP请求从Web服务器请求特定文件。Web服务器将做出响应，再次通过HTTP向浏览器发送请求的页面。如果请求的页面不存在或出现问题，则Web服务器将响应并显示一条错误消息。然后，浏览器将能够显示该网页。一台Web服务器上也可以托管多个域。
49、应用程序服务器(Application server)
用程序服务器是分布式网络中计算机中的服务器程序，它为应用程序提供业务逻辑。通常将应用程序服务器视为三层应用程序的一部分，该三层应用程序由图形用户界面（GUI）服务器，应用程序（业务逻辑）服务器以及数据库和事务处理服务器组成。更具描述性地，可以将其视为将应用程序划分为：
1.基于Web浏览器的第一层，前端，图形用户界面，通常在个人计算机或工作站上。
2.中间层业务逻辑应用程序或一组应用程序，可能在局域网或Intranet服务器上。
3.第三层后端，数据库和事务服务器，有时在大型机或大型服务器上。
在许多用法中，应用程序服务器与Web（超文本传输协议）服务器结合或一起使用，称为Web应用程序服务器。Web浏览器为用户提供了一个易于创建的基于HTML的前端。Web服务器提供了几种不同的方式将请求转发到应用程序服务器，以及将修改后的网页或新的Web页面转发回用户。这些方法包括通用网关接口（CGI），FastCGI，Microsoft的Active Server Page和Java Server Page。在某些情况下，Web应用程序服务器还支持请求“代理”接口，例如CORBA Internet Inter-ORB协议（IIOP）。
50、数据库服务器(Database server)
数据库服务器可以指用于运行数据库的硬件和软件。遵循传统的客户端-服务器模型，数据库服务器作为软件，是数据库应用程序的后端部分。该后端部分有时称为实例。它还可能是指用于承载数据库的物理计算机。在本文中提到时，数据库服务器通常是承载数据库的专用高端计算机。

请注意，数据库服务器独立于数据库体系结构。关系数据库，平面文件，非关系数据库：所有这些体系结构都可以容纳在数据库服务器上。
在客户端服务器计算模型中，有一个专用主机来运行和提供资源，通常是一个或多个软件应用程序。还有几个客户端可以连接到服务器并使用此服务器提供和托管的资源。
在考虑客户机/服务器模型中的数据库时，数据库服务器可能是数据库应用程序（实例）的后端，也可能是承载实例的硬件计算机。有时，它甚至可以指硬件和软件的组合。
在中小型设置中，硬件数据库服务器通常还将托管使用该数据库的软件应用程序的服务器部分。例如，如果我们考虑银行，则硬件数据库服务器将托管软件数据库服务器和银行的软件应用程序。该应用程序可能会通过特定的端口连接到数据库，并使用进程间通信来登录和访问驻留在数据库中的数据。银行中坐在个人计算机上的用户也将使用计算机上安装的应用程序的客户端模块来连接数据库。在此示例中，实际上我们正在查看两种客户端-服务器模型：数据库和应用程序。
在较大的设置中，事务量可能使得一台计算机将无法处理负载。在这种情况下，数据库软件将驻留在专用计算机上，而应用程序将驻留在另一台计算机上。在这种情况下，有一个专用的数据库服务器（由硬件和软件组成）和一个单独的专用应用程序服务器。

6) 第六类关键词

51、面向对象设计(Object-oriented design)
在分析阶段之后，使用面向对象设计（OOD）将概念模型进一步开发为面向对象模型。在OOD中，将分析模型中与技术无关的概念映射到实现类上，确定约束并设计接口，从而形成用于解决方案领域的模型。简而言之，构建了详细的说明，指定如何在具体技术上构建系统。
我们的高校人事管理系统主要有三个角色，管理员可以审核反馈信息、工资管理、审核请假申请、用户管理、职位管理；教师和工勤人员可以查看基本信息、查看工资和提交反馈信息。

面向对象设计的阶段可以标识为：
• 系统上下文的定义
• 设计系统架构
• 识别系统中的对象
• 设计模型的构建
• 对象接口规范
面向对象的系统设计涉及定义系统的上下文，然后设计系统的体系结构。
• 上下文-系统的上下文具有静态和动态部分。使用整个系统的简单框图设计系统的静态上下文，该框图被扩展为子系统的层次结构。子系统模型由UML包表示。动态上下文描述了系统如何与其环境交互。使用用例图对其进行建模。
• 系统体系结构-系统体系结构是根据体系结构设计原则以及领域知识在系统上下文的基础上进行设计的。通常，将系统划分为几层，然后分解每一层以形成子系统。
分解意味着按照分而治之的原则，将一个大型的复杂系统划分为具有较小复杂性的较小组件的层次结构。系统的每个主要组成部分都称为子系统。面向对象的分解可识别系统中的各个自治对象以及这些对象之间的通信。
分解的优点是-
• 各个组件的复杂度较低，因此更易于理解和管理。
• 它可以使具有专业技能的劳动力分工。
• 它允许替换或修改子系统而不会影响其他子系统。

52、软件再利用(Software reuse)
软件重用的定义是从预定义的软件组件创建软件系统的过程。
比如我们高校人事管理系统，教师与后勤人员的系统操作界面基本相同，这里我们就可以使用代码重用来减少开发的消耗等。
软件重用的优点：

1. 可重用组件的系统开发。
2. 这些组件的系统重用作为构建新系统的基础。
   可重用的组件可能是代码，但是重用的更大好处来自对可重用内容的更广泛和更高层次的了解。软件规范，设计，测试用例，数据，原型，计划，文档，框架和模板都是重用的候选对象。
   软件重用可以减少软件开发时间和成本。软件重用的主要优点是：
3. 提高软件生产率。
4. 缩短软件开发时间。
5. 改善软件系统的互操作性。
6. 用更少的人开发软件。
7. 在项目之间更轻松地移动人员。
8. 降低软件开发和维护成本。
9. 产生更多标准化的软件。
10. 产生质量更高的软件，并提供强大的竞争优势。

53、软件设计模式(Design patterns)
设计模式(英语 design pattern)是对面向对象设计中反复出现的问题的解决方案。这个术语是在1990年代由Erich Gamma等人从建筑设计领域引入到计算机科学中来的。这个术语的含义还存有争议。算法不是设计模式，因为算法致力于解决问题而非设计问题。设计模式通常描述了一组相互紧密作用的类与对象。设计模式提供一种讨论软件设计的公共语言，使得熟练设计者的设计经验可以被初学者和其他设计者掌握。设计模式还为软件重构提供了目标。
设计模式用于表示由经验丰富的面向对象软件开发人员改编的一些最佳实践。设计模式系统地命名，激励和解释了解决面向对象系统中反复出现的设计问题的通用设计。它描述了问题，解决方案，何时应用解决方案及其后果。它还提供了实现提示和示例。
创建型模式：
　　1. 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
　　2. 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
　　3. 工厂方法（Factory Method）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
　　4. 抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
5. 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
结构型模式：
　　1. 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
　　2. 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
　　3. 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
　　4. 装饰（Decorator）模式：动态的给对象增加一些职责，即增加其额外的功能。
　　5. 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
　　6. 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
　　7. 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
行为型模式：
　　1. 模板方法（TemplateMethod）模式：定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
　　2. 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
　　3. 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
　　4. 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
　　5. 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。
　　6. 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
　　7. 中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
　　8. 迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
　　9. 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
　　10. 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
　　11. 解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

54、类别图(Class diagrams)
类图是静态图。它表示应用程序的静态视图。类图不仅用于可视化，描述和记录系统的不同方面，而且还用于构造软件应用程序的可执行代码。类图描述了类的属性和操作以及对系统施加的约束。由于类图是唯一的UML图，可以直接使用面向对象的语言进行映射，因此它们被广泛用于面向对象系统的建模中。类图显示了类，接口，关联，协作和约束的集合。也称为结构图。
类图的目的是为应用程序的静态视图建模。类图是唯一可以直接用面向对象的语言映射的图，因此在构造时被广泛使用。
UML图（例如活动图，序列图）只能给出应用程序的序列流，但是类图则有些不同。它是编码器社区中最流行的UML图。
类图的目的是为应用程序的静态视图建模。类图是唯一可以直接用面向对象的语言映射的图，因此在构造时被广泛使用。
UML图（例如活动图，序列图）只能给出应用程序的序列流，但是类图则有些不同。它是编码器社区中最流行的UML图。
类图的目的可以概括为：
• 分析和设计应用程序的静态视图。
• 描述系统的职责。
• 组件图和部署图的基础。
• 正向和反向工程。

55、开源程序(Open-source code)
开源软件（英文全称：Open source software，英文缩写：OSS，中文全称：开放源代码软件）是一种源代码可以任意获取的计算机软件，这种软件的版权持有人在软件协议的规定之下保留一部分权利并允许用户学习、修改、增进提高这款软件的质量。开源协议通常符合开放源代码的定义的要求。一些开源软件被发布到公有领域。开源软件常被公开和合作地开发，开放源代码软件是开源发展的最突出的例子，也经常与用户生成内容（user-generated content）做比较。开源软件的英文“open-source software”一词出自free software（自由软件）的营销活动中。Standish集团一份报告指出，采用开放源代码软件的模式让消费者每年节省60亿美元。
我们高校人事管理系统也本着开源的理念，将代码开源，可供更多的开发人员参考和提出意见，这样才能我们的系统才会更加地完善。

56、静态模型(Static model)
OOA和OOD活动都使用静态模型。下图中显示了另一个静态视图，用于说明对象分解，并提供了有关ATM Machine对象的更详细的视图。描述了ATM机与客户显示，交易和打印机组件之间的整体关系的汇总。继承与现金提取和支票存款一起显示为父交易的派生对象。

静态模型的另一种形式是如下图所示的模块架构图。这用于OOD阶段，并说明静态体系结构实体及其接口。每个设计图标都描述了用于与封装在图标边界内的对象之间收发消息的接口。可以通过连接对象的线上的箭头方向指示消息流。

57、动态模型(Dynamic model)
动态模型，是指描述系统各组成部分之间及系统与外界之间的平衡关系以及这些关系的运动过程的模型。如系统动力学模型，弹簧振子的位移方程式等。动态模型能反映系统在运动变化过程中各种因素相互作用的动态特征，与静态模型相比，它加进了时间因素，因而能更有效地实现对真实系统的模拟。
动态模型描述与操作时间和顺序有关的系统特征、影响更改的事件、事件的序列、事件的环境以及事件的组织。
借助时序图、状态图和活动图，可以描述系统的动态模型。动态模型的每 个图均有助于理解系统的行为特征。对于开发人员来说，动态建模具有明确性、可视性和简易性的特点。
大量成功的软件工程实践难了动态模型的补助性，而动态模型的优越性使得该方法被广泛接受。动态建模的优势性列举如下：
1：如同建筑物或永恒的建筑模型可显示施工场地的结构和设计一样，动态模型使用户和开发人员能更容易地理解构思中的系统。
2：建模有助于解释状态的更改，并通过将不重要的方面与重要的方面分开而子降低复杂度。借助每个状态图和时序图可降低系统的复杂度。
3：借助于动态模型，可监视构思中的系统是否存在任何类型的缺陷，如果在开发开始后才发现这些缺陷，则可能需要付出昂贵的代价。
4：维护模型比维护系统容易得多，成本也降低了很多。

58、接口规格(Interface specification)
标准接口在系统设计过程中发挥着重要的作用，可为设计实现互操作性与低成本，并减少设计所需的时间，但对需要实现产品差异化的设计团队而言，其实用性仍然很用限。设计人员还应依赖芯片厂商为其提供各种多组合标准接口。对芯片厂商而言，可帮助高效实施接口的高质量软件是实现差异化的其它因素。提供更高级别的灵活性也非常有帮助，能够通过TIPRU与UPP等可配置接口获得。系统设计人员利用其工具套件中的这些选项，即可发挥创造性，同时又能保持组件的低成本。

59、状态机模型(State machine model)
状态机模型：要求设计者要考虑所有可能的状态，以及所有可能输入条件下可能进行的所有状态转移。
时序程序模型：它是通过一系列可重复执行或有条件执行的指令来变换数据的。状态机模型在许多场合中用来描述效果更好。因为用状态机来进行描述提供了更自然的计算方法。

60、约束块参数图(Constraint Block Parametrics Diagram)

1、约束块参数化图模式创建元素和一个图，表示在边界约束块上下文中三个约束块的用法。约束属性的参数相互绑定，然后绑定到边界约束块的参数，有效地描述方程组。
2、该模式的目的是允许系统工程师创建可用于约束块或约束块特性的方程组。
3、当控制或约束行为的约束和方程已确定时，通常在分析阶段使用该模式。用法包括：
·它们可以用作模拟的前光标，用于可视化方程和执行详细分析。
·它们可以作为权衡研究的基础。
·它们可以作为记录系统方程的形式化方法，以及它们在边界约束块的上下文中如何相互关联。

7）第七类关键词

61、工作流程管理系统(Workflow Management Systems)
工作流管理系统是旨在帮助创建，维护和存储信息的工作流程的各个部分的计算机系统。这种系统的目的是通过强调可以更快移动的事物和可以提高效率的领域来帮助创建报告和其他有用的数据，从而改善工作流程并帮助提高生产率。工作流管理是工作世界中一个相当新的概念。本质上，工作流管理的思想是，通过管理数据，文档，线索和其他与工作相关的项目的进度，可以简化工作流程，并且可以轻松记录流程中的任何故障。

工作流管理系统可用于收集有助于改进流程的数据和报告。
在当今的业务环境中，出于多种原因使用工作流管理系统。越来越多地使用和遵守工作流管理系统的一个主要原因是该系统可用于跟踪员工绩效。通过将所有内容记录到工作流管理系统中，如果以后出现问题，则很容易看到问题的根源并采取适当的措施。这样，可以确认每个员工都在正确，及时地完成工作。员工还可能对未及时完成或未正确完成的工作负责。
工作流管理系统的另一个用途是协助客户服务过程。为此目的使用的工作流管理系统通常称为客户关系管理系统或CRM。CRM通过确保客户服务人员可以访问详细记录来帮助客户进行投诉，从而帮助客户服务。这些系统还跟踪与客户的每一次联系，以便为可能出现的任何问题找到“与谁交谈”的证据。CRM还可在采用CRM的公司认为合适的任何时候对客户进行营销。
这样的系统还可以提高工厂环境中的生产率和产量。通过使用工作流管理系统跟踪从原材料到成品的生产过程，可以更轻松地识别生产周期中的瓶颈。识别导致延迟或过多工作和成本的低效率流程也将变得更加容易。因此，使用工作流管理系统可以成为提高任何公司的生产力，问责制和客户关系的好方法。

62、结构化分析 (Structured Analysis)
结构化概念在结构化分析方法中达到了顶峰，该方法目前以多种形式存在。在结构化分析方法中，当前的应用程序系统被捕获在“数据流程图”中。该技术本身主张将逻辑设计和物理实现分开。为此，现有的数据存储被视为旧的物理模型，并从中得出了新的逻辑模型。如果没有以前的系统，则将手动过程视为一个系统进行分析并记录下来。然后，这种新的逻辑设计将重点放在完成了什么而不是如何完成上。
然后可以将更改应用于包含客户所需更改的逻辑模型。更改后的模型将成为甚至更“新”的新模型，并转换为新的物理模型以供实施。由于这种方法对业务问题和程序解决方案之间的关系的演变产生了影响，因此改进了模块化的概念。这种改进使程序模块的结构，模块之间的接口和通信限制以及质量测量变得统一。后来，这段时间中的一些重要发现对于形成面向对象设计的概念根源很有用，我们将在其他地方更详细地介绍这些概念。

63、 异步动作 (Asynchronous Action)

在工作流程执行期间，Mistral最终会运行操作。动作是与工作流任务相关联的特定功能（或一项工作）。 动作可以是同步的也可以是异步的。 同步动作是在没有第三方的情况下完成的动作，即由Mistral本身完成的动作。当Mistral引擎计划运行同步操作时，它将其定义和参数发送给Mistral执行器，然后执行器运行它，并在完成后将操作结果发送回Mistral引擎。 对于异步操作，执行程序不会将结果发送回Mistral。实际上，异步操作的概念假定执行程序运行它时，结果将不会为人所知。而是假设该操作只会将实际工作委托给第三方，该第三方可以是人为系统或计算机系统（例如Web服务）。因此，异步操作的run（）方法应该只是向能够执行所需工作的对象发送信号。 一旦第三方完成工作，它就有责任通过Mistral API将操作结果发送回Mistral。实际上，第三方只需要更新相应动作执行对象的状态即可。为了使其成为可能，它必须知道相应的动作执行ID。 值得注意的是，从Mistral引擎的角度来看，在同步和异步操作的情况下，架构本质上是相同的。如果动作是同步的，则执行器在动作完成后立即使用RPC机制（通常是消息队列作为传输）将结果发送回Mistral引擎。但是引擎本身并没有主动等待任何东西，它的架构完全基于异步消息。因此，在异步操作的情况下，唯一的变化是执行者不负责发送操作结果，其他事务接管了执行者。 让我们看看使用异步操作时需要记住的内容。

64、车道流程图(Business Process Diagram with Lanes)

1、车道的目的是组织和分类流动对象，通常用于指示谁执行或负责车道中包含的活动。这些通道可用于其他目的，例如指示正在执行活动的位置或谁管理一组活动。
2、模式可以在计划的任何时候使用，但通常在绘制基线（当前状态）过程或定义目标（未来状态）过程的早期使用。对于一个组织来说，在一个企业或业务单元级别开始详细描述所有基线（当前状态）过程是非常常见的，这样这些过程是可用的，并且可以被多个项目重用。
3、首先开始注册事件，教师进行注册账号，系统判断是否有该账号，如果已被注册了，就提示该账号不可用，返回重新注册，该流程2结束；如果账号没有被注册过，就由管理员进行审核，如果通过审核，就注册成功，流程结束；否侧注册失败，可以重新尝试注册。

65、业务流程图(Basic Business Process)

1、基本业务流程模式使用埃里克森-彭克语言创建元素和图表来表示业务流程和交互。
该语言提供了一种对业务流程建模的内聚方式，它允许建模者在一个综合的、有表现力的图中表示目标、触发流程的事件以及流程的输入和输出。
2、该模式的目的是允许业务分析师、架构师和其他涉众创建和查看一个简单但富于表现力的图表，该图表在一个视图中捕获流程的所有方面。
3、该模式可在计划期间的任何时间使用，但通常在分析期间用于描述基线(当前)和目标(未来)流程。

66、模型图(Domain Model)

1、领域模型模式在一个类图上创建类，该类图描述了正在讨论的领域中的重要概念或“事物”。 类可以命名，也有详细的注释。
连接器被用来描述元素之间的关系，就像动词在自然语言中被用来描述名词如何相互作用一样。
2、其目的是为一个领域中的重要概念创建一个模型，该模型可用作一种通信设备，以确保所有利益相关者对概念有一个共同且一致的理解。
3、领域模型通常是在一个计划中创建的第一批模型之一，它构成了开发存储库其他部分的基础。 它可以像字典一样被用作交流工具。

67、性能规范(Performance Specifications)
安全性能指南和选项中描述的安全措施和建议的性能规格、性能规格。本章包括安全系统的近40个独立组件和子组件的性能规格。对于每个系统组件，都提供了它如何影响组织的整体安全性以及如何实现的描述。它们包括门禁控制、报警系统、闭路电视系统、门、电子门禁系统、照明、锁系统、自然屏障、屋顶通道、安保人员、标志、窗户等。

68、敏捷式项目管理(Agile project management)
敏捷项目管理是在项目的整个生命周期中交付项目的迭代方法。
迭代或敏捷生命周期是由几个迭代或渐进步骤组成的，直到项目完成。迭代方法经常在软件开发项目中使用，以提高速度和适应性，因为迭代的好处是你可以随着时间的推移而调整，而不是沿着一条线性的路径。敏捷或迭代方法的目标之一是在整个过程中释放收益，而不仅仅是在最后。在核心，敏捷项目应该展示信任、灵活性、授权和协作的核心价值和行为。

69、极致程序设计(Extreme programming)
极限编程(eXtreme Programming，XP)是为了解决小团队在面对模糊和不断变化的需求时软件开发的特定需求而构思和开发的。
极限编程是敏捷软件开发方法之一。它提供了指导团队行为的价值观和原则。该团队有望自我组织。极限编程提供了特定的核心实践，其中
每次练习都很简单，自我完成。
实践的结合产生了更复杂和紧急的行为。

70、计划驱动式开发(Plan-driven development)
一种开发风格，试图预先计划和预测用户在最终产品中可能想要的所有特性，并确定如何最好地构建这些特性。工作计划是基于一系列特定工作阶段的执行。

三、 对我组高校人事管理系统的发展建议

1) 对我组认识管理系统的目前现状的认识

我们组的高校人事管理系统是建立在现有的高校旧人事管理系统的基础上的，希望能够设计出一个比旧系统高校而且部署在网上的应用系统，以web端为管理员端、手机APP端为用户端的认识管理系统。所以我们以关键涉众（教职工、领导）的需求为主做出了整个高校人事管理系统的需求分析，但是这个系统的功能相对于市面上的其他系统来说并没有特别突出的优势，真正开发起来，如果没有大量资金来创造价格优势的话，很难迅速打开市场，甚至可能找不到愿意购买使用的高校买方。

2) 对我组人事管理系统的发展建议

我组的人事管理系统应该除了已经设计的功能之外，再加入一些独特的功能，让人眼前一亮，比如加入课表功能，除了能够查看日常课表之外，在节假日或是其他老师因事无法授课能够及时通知到其他的老师，避免课程时间的浪费或是课程顺延拖慢学期的教学进度。
当然，除此之外，质量需求也是非常重要的，如果我们组的高校人事管理系统能够保持连续一个月不出错运行同时数据不丢失的话，相信会更加吸引客户；同时，系统的响应时间也不能太长，特别是早上打卡人数巅峰期更要保持高效的响应时间。
我对我们组的高校人事管理系统的建议也没有太多，毕竟在需求分析时就已经考虑得够多了，市面上的人事管理系统也已经接近人事系统能做到的最好的了。

四、 参考书目

引用书目：
[1]骆斌，丁二玉，需求工程-软件建模与分析（第2版）。北京：高等教育出版社，2015.2。
[2][Hofmann 2001] HOFMANN H F, LEHNER F. Requirements engineering as a success factor in software projects. 2001,18(4): 58 – 66.
[3][Wiegers 2003] WIEGERS K. Software requirements. 2nd ed. Redmond: Microsoft Press, 2003.

A002-181-2154相关推荐

1. Python 开源项目大集合，跨 15 个领域，181 个项目

   关注上方"深度学习技术前沿",选择"星标公众号", 资源干货,第一时间送达! 人生苦短,越来越多的人,都开始用 Python 了. 但寻找好的项目资源,费时又费 ...

2. http://www.jikexueyuan.com/course/181.html

   http://www.jikexueyuan.com/course/181.html  html5的学习 转载于:https://www.cnblogs.com/ios1/p/4462458.html

3. python整数二进制有多少个1_LintCode Python 入门级题目 365.二进制有多少个1； 181.将整数A转换为B...

   原题365描述: 计算在一个 32 位的整数的二进制表式中有多少个 1. 您在真实的面试中是否遇到过这个题? Yes 样例 给定 32 (100000),返回 1 给定 5 (101),返回 2 给定 ...

4. 181个NLP教程合集，Colab一键直达，无需环境配置，此外还有481个文本数据集

   梅宁航 发自 凹非寺  量子位 报道 | 公众号 QbitAI 学习NLP不用愁了. 算力.环境配置谷歌提供,Colab套件对NLP全场景支持. 有了算力,还差教程,现在NLP学习合集大全套来了. △ ...

5. 成功解决bs4\__init__.py:181: UserWarning: No parser was explicitly specified, so I'm using the best avai

   解决问题 bs4\__init__.py:181: UserWarning: No parser was explicitly specified, so I'm using the best ava ...

6. 【BZOJ】【2154】Crash的数字表格

   莫比乌斯反演 PoPoQQQ讲义第4题 题解:http://www.cnblogs.com/jianglangcaijin/archive/2013/11/27/3446169.html 感觉两次sq ...

7. fzu 2154 YesOrNo

   Problem 2154 YesOrNo Accept: 14    Submit: 29 Time Limit: 1000 mSec    Memory Limit : 32768 KB Probl ...

8. JEP 181不兼容，嵌套类/ 2

   JEP 181是基于嵌套的访问控制https://openjdk.java.net/jeps/181 . 它是在Java 11中引入的,它故意引入了与先前版本的不兼容性. 这是一个很好的例子,与Jav ...

9. [资源]181个Python开源项目分享！

   在基于 GitHub 2018 年 Octoverse 报告中,简要分析了 Github 中哪些编程语言是最佳代表或是趋势. 有许多方法可以衡量编程语言的流行程度. 在Octoverse报告中,Git ...

10. ssh报错解决 ECDSA host key for 123.56.11.181 has changed and you have requested strict checking.

    起因:云服务器重装了系统,导致本地的SSH信息便失效了,所以会报错. 解决办法: ssh-keygen -R 123.56.11.181 目的是清除本地关于远程服务器的缓存和公钥信息.

最新文章

1. JVM 有 Full GC，为什么还会出现 OutOfMemoryError呢?
2. 关于js中cookie的认识
3. 每日一皮：自己运行正常，测试一测就有bug
4. expect spawn、linux expect 用法
5. 如何设置窗口立即刷新显示
6. mysql5.7.19带源码_CentOS7 + Nginx1.13.5 + PHP7.1.10 + MySQL5.7.19 源码编译安装
7. 从阿里中台战略看企业IT架构转型之道（上）
8. Linux C获取文件属性
9. Spring Security OAuth2.0_实现分布式认证授权_微服务解析令牌并鉴权_Spring Security OAuth2.0认证授权---springcloud工作笔记154
10. 用MATLAB解决实际数学问题,用matlab解决一道数学问题
11. 数据库读现象和隔离级别
12. JAVA基础第四章-集合框架Collection篇
13. Cocoa与Cocoa Touch区别
14. FPGA知识汇集-值得收藏的FPGA代码命名规范？
15. Set接口下的三个实用类
16. LeetCode-1264. 页面推荐（中等）
17. 升级win11后，觉得不好用想重装win10系统？教你重装win10“精简版”
18. 移动端特点(重点)~~~
19. 各类VRP问题标准算例资源汇总
20. python2鼠标键盘录制功能以及还原操作功能

热门文章

1. CD光盘和电报的编码
2. photoshop旋转图片
3. Python画樱花树
4. STM32软件模拟IIC---读写驱动AT24Cxx
5. html5跟随手指的小球,Android自定义圆形View实现小球跟随手指移动效果（详细介绍）...
6. 虚幻引擎构建光照失败的原因_如何在虚幻引擎4中构建实时动态封面系统
7. 从头认识Spring-1.14 SpEl表达式（3）-SpEl表达式的两个坑：Bean的顺序与Bean的toString方法
8. apache基于端口的虚拟主机配置
9. 一个英语学渣是如何通过英语六级的
10. html实现在线聊天,利用HTML5实现电脑端微信聊天窗口界面