作业A002-185-2502-李林
课程名称 软件需求分析与建模
班级 18软件工程5班
教导教师 董瑞生
李林 1814080902502
日期 2020.12.15

---

目录

---

---

1、Excel查找结合项目主题说明

1.1第一次查词

1.1.1 判定表（Decision table）

https://www.techopedia.com/definition/18829/decision-table-detab

A decision table is used to represent conditional logic by creating a list of tasks depicting business level rules. Decision tables can be used when there is a consistent number of conditions that must be evaluated and assigned a specific set of actions to be used when the conditions are finally met. Decision tables are fairly similar to decision trees except for the fact that decision tables will always have the same number of conditions that need to be evaluated and actions that must be performed even if the set of branches being analyzed is resolved to true. A decision tree, on the other hand, can have one branch with more conditions that need to be evaluated than other branches on the tree.

决策表通过创建描述业务级规则的任务列表来表示条件逻辑。当有一致数量的条件必须进行评估并分配一组特定的操作，当这些条件最终满足时，可以使用决策表。决策表与决策树非常相似，只是决策表始终具有相同数量的需要评估的条件和必须执行的操作，即使所分析的分支集被解析为正确。另一方面，决策树可以有一个分支比树上的其他分支具有更多需要评估的条件。

1.1.2指导委员会（Steering committee）

https://www.reference.com/business-finance/function-steering-committee-5da

The function of a steering committee is to provide support, advocacy and enablement for the projects which they oversee. A steering committee is not designed to actually manage or run a project, and should be kept from doing so. Rather, the steering committee should facilitate the project manager’s ability to plan and direct a given project, giving advice and support along the way.Steering committees function best when the scope of their responsibilities and purposes are clearly defined. They often function as a decision-making body, determining the budgets, time lines and personnel for the projects they oversee. A steering committee should not be loaded up with members who are not needed; instead, every member on the committee should have a specific function tied to oversight, recording of decisions, budgeting or other specific skills needed depending on the project.

指导委员会的职能是为他们监督的项目提供支持、宣传和支持。指导委员会并不是为实际管理或管理一个项目而设计的，应该阻止它这样做。相反，指导委员会应该促进项目经理计划和指导一个给定项目的能力，并在整个过程中提供建议和支持方向。转向当委员会的职责范围和宗旨被明确界定时，委员会的运作最好。他们通常是一个决策机构，决定他们所监督的项目的预算、时间表和人员。指导委员会不应配备不需要的成员；相反，委员会中的每一位成员都应具有与监督、决策记录、预算编制或其他具体技能相关的具体职能，具体取决于项目。

1.1.3类（Class model）

https://www.excelsoftware.com/classmodel

A Class is a standard UML construct used to detail the pattern from which objects will be produced at run-time. A class is a specification - an object an instance of a class. Classes may be inherited from other classes (that is they inherit all the behavior and state of their parent and add new functionality of their own), have other classes as attributes, delegate responsibilities to other classes and implement abstract interfaces. The Class Model is at the core of object-oriented development and design - it expresses both the persistent state of the system and the behavior of the system. A class encapsulates state (attributes) and offers services to manipulate that state (behavior). Good object-oriented design limits direct access to class attributes and offers services which manipulate attributes on behalf of the caller. This hiding of data and exposing of services ensures data updates are only done in one place and according to specific rules - for large systems the maintenance burden of code which has direct access to data elements in many places is extremely high.

类是一个标准的UML构造，用于详细说明在运行时将从中生成对象的模式。类是一个规范-一个对象是一个类的实例。类可以从其他类继承（即继承其父类的所有行为和状态并添加自己的新功能）、将其他类作为属性、将职责委托给其他类并实现抽象接口。类模型是面向对象开发和设计的核心，它表达了系统的持久状态和系统的行为。类封装状态（属性）并提供服务来操作状态（行为）。好的面向对象设计限制了对类属性的直接访问，并提供了代表调用方操作属性的服务。这种数据隐藏和服务公开确保了数据更新只在一个地方进行，并且根据特定的规则进行——对于大型系统来说，在许多地方可以直接访问数据元素的代码的维护负担非常高。

1.1.4上下文模型（Context model）

http://ctxmodel.net/

Context Model is a divide-and-conquer method based on separation of data into subsequences by context, so that each subsequence can be approximated with a simple model (usually memoryless) while still providing a good overall precision. Most widely used CM subclass is PPM, which concentrates on a single context model due to performance considerations and switches to other contexts only if the main model fails. This allows PPM compressors to keep competitive speed at the cost of some prediction imprecision showing as redundancy. Another known subclass is Context Mixing, which linearly combines the predictions of several submodels. More complex schemes with secondary models using the primary predictions as context seem to remain anonymous. Then, there’s yet another approach which also approximates complex data with simple model but by a static data transformation (LZ, Block Sorting, Symbol Ranking). Strange as it may seem, CM too is only a speed/redundancy tradeoff stage, as an ultimate modelling method is to find a function which generates given data. There’re even some practical applications for this in the cases with known source model, then parameters can be determined by maximum likelihood.

模型是一种分而治之的方法，它将数据按上下文分解为子序列，这样每个子序列都可以用一个简单的模型（通常是无记忆的）来近似，同时仍然提供了良好的整体精度。最广泛使用的CM子类是PPM，出于性能考虑，它集中于单个上下文模型，只有在主模型失败时才会切换到其他上下文。这使得PPM压缩器能够保持具有竞争力的速度，但代价是某些预测不精确，显示为冗余。另一个已知的子类是上下文混合，它线性地组合了几个子模型的预测。更复杂的方案与次级模型使用主要预测作为上下文似乎是匿名的。然后，还有另一种方法，用简单的模型来近似复杂的数据，但是通过静态数据转换（LZ、块排序、符号排序）。奇怪的是，CM也只是一个速度/冗余的权衡阶段，因为最终的建模方法是找到一个生成给定数据的函数。在已知源模型的情况下，甚至有一些实际应用，然后用极大似然法确定参数。

1.1.5操作顺序（Action sequence）

https://wiki.pentaho.com/display/ServerDoc2x/03.+Action+Sequences

The Action Sequence is an XML document that defines the smallest complete task that the solution engine can perform. It is executed by a very lightweight process flow engine and defines the order of execution of one or more the components of the Pentaho BI Platform. We avoid calling this a process flow because it is missing many of the capabilities of a true process flow engine. It is good for sequencing small, linear, success oriented tasks like reporting and bursting. It has the ability to loop through a result set, call another Action Sequence and conditionally execute components. The Action Sequence document should have a “.xaction” suffix.

操作序列是一个XML文档，它定义了解决方案引擎可以执行的最小的完整任务。它由一个非常轻量级的流程引擎执行，并定义Pentaho BI平台的一个或多个组件的执行顺序。我们避免将其称为流程流，因为它缺少真正流程流引擎的许多功能。它有利于排序小，线性，面向成功的任务，如报告和爆破。它能够遍历一个结果集，调用另一个操作序列并有条件地执行组件。操作序列文档应具有“.xaction”后缀。

1.1.6数据流图（dataflow diagram）

https://www.lucidchart.com/pages/data-flow-diagram
https://www.visual-paradigm.com/guide/data-flow-diagram/what-is-data-flow-diagram/

A data flow diagram (DFD) maps out the flow of information for any process or system. It uses defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs, outputs, storage points and the routes between each destination. Data flowcharts can range from simple, even hand-drawn process overviews, to in-depth, multi-level DFDs that dig progressively deeper into how the data is handled. They can be used to analyze an existing system or model a new one. Like all the best diagrams and charts, a DFD can often visually “say” things that would be hard to explain in words, and they work for both technical and nontechnical audiences, from developer to CEO. That’s why DFDs remain so popular after all these years. While they work well for data flow software and systems, they are less applicable nowadays to visualizing interactive, real-time or database-oriented software or systems.
Also known as DFD, Data flow diagrams are used to graphically represent the flow of data in a business information system. DFD describes the processes that are involved in a system to transfer data from the input to the file storage and reports generation.

Data flow diagrams can be divided into logical and physical. The logical data flow diagram describes flow of data through a system to perform certain functionality of a business. The physical data flow diagram describes the implementation of the logical data flow.
DFD graphically representing the functions, or processes, which capture, manipulate, store, and distribute data between a system and its environment and between components of a system. The visual representation makes it a good communication tool between User and System designer. Structure of DFD allows starting from a broad overview and expand it to a hierarchy of detailed diagrams. DFD has often been used due to the following reasons:
Logical information flow of the system
Determination of physical system construction requirements
Simplicity of notation
Establishment of manual and automated systems requirements

数据流图（DFD）描绘出任何过程或系统的信息流。它使用定义好的符号（如矩形、圆圈和箭头）以及短文本标签来显示数据输入、输出、存储点和每个目的地之间的路由。数据流程图可以从简单的甚至手绘的过程概览到深入挖掘数据处理方式的深入、多级DFD。它们可用于分析现有系统或为新系统建模。像所有最好的图表一样，DFD通常可以直观地“说出”难以用语言解释的事情，它们为技术和非技术受众工作，从开发人员到CEO。这就是为什么DFD在这么多年后仍然如此受欢迎。虽然它们适用于数据流软件和系统，但现在不太适用于可视化交互式、实时或面向数据库的软件或系统。
也称为DFD，数据流图用于以图形方式表示业务信息系统中的数据流。DFD描述了系统中涉及的将数据从输入传输到文件存储和生成报告的过程。
数据流图可分为逻辑流图和物理流图。逻辑数据流图描述了通过系统执行业务特定功能的数据流。物理数据流图描述了逻辑数据流的实现。
以图形方式表示功能或过程的DFD，这些功能或过程捕获、操作、存储和分发系统与其环境之间以及系统组件之间的数据。可视化表示使其成为用户与系统设计者之间的良好沟通工具。DFD的结构允许从一个广泛的概述开始，并将其扩展到一个详细的图的层次结构。由于以下原因，经常使用DFD：
系统逻辑信息流
物理系统建设要求的确定
符号的简单性
建立手动和自动系统要求

1.1.7主动类（Active class）

https://www.lucidchart.com/pages/uml-class-diagram

Class diagrams are one of the most useful types of diagrams in UML as they clearly map out the structure of a particular system by modeling its classes, attributes, operations, and relationships between objects. With our UML diagramming software, creating these diagrams is not as overwhelming as it might appear. This guide will show you how to understand, plan, and create your own class diagrams.
One of the more popular types in UML is the class diagram. Popular among software engineers to document software architecture, class diagrams are a type of structure diagram because they describe what must be present in the system being modeled. No matter your level of familiarity with UML or class diagrams, our UML software is designed to be simple and easy to use.UML was set up as a standardized model to describe an object-oriented programming approach. Since classes are the building block of objects, class diagrams are the building blocks of UML. The various components in a class diagram can represent the classes that will actually be programmed, the main objects, or the interactions between classes and objects. The class shape itself consists of a rectangle with three rows. The top row contains the name of the class, the middle row contains the attributes of the class, and the bottom section expresses the methods or operations that the class may use. Classes and subclasses are grouped together to show the static relationship between each object.

UML中比较流行的一种类型是类图。类图是一种结构图，在软件工程师中很流行，因为类图描述了被建模的系统中必须存在的内容。无论您对UML或类图的熟悉程度如何，我们的UML软件都是设计为简单和易于实现的使用.UML作为一个标准化的模型来描述面向对象的编程方法。因为类是对象的构建块，所以类图是UML的构建块。类图中的各种组件可以表示实际编程的类、主要对象或类与对象之间的交互。类形状本身由一个有三行的矩形组成。顶行包含类的名称，中间一行包含类的属性，底部部分表示类可能使用的方法或操作。类和子类被组合在一起以显示每个对象之间的静态关系。
类图是UML中最有用的图表类型之一，因为类图通过对特定系统的类、属性、操作和对象之间的关系进行建模来清晰地描绘出特定系统的结构。使用我们的UML图表软件，创建这些图表并不像看上去那么令人难以接受。本指南将向您展示如何理解、规划和创建您自己的类图。

1.1.8构件图（Component diadram）

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-component-diagram/
https://www.tutorialspoint.com/uml/uml_component_diagram.htm

UML Component diagrams are used in modeling the physical aspects of object-oriented systems that are used for visualizing, specifying, and documenting component-based systems and also for constructing executable systems through forward and reverse engineering. Component diagrams are essentially class diagrams that focus on a system’s components that often used to model the static implementation view of a system.
Component diagrams are different in terms of nature and behavior. Component diagrams are used to model the physical aspects of a system. Now the question is, what are these physical aspects? Physical aspects are the elements such as executables, libraries, files, documents, etc. which reside in a node.
Component diagrams are used to visualize the organization and relationships among components in a system. These diagrams are also used to make executable systems.
Component diagram is a special kind of diagram in UML. The purpose is also different from all other diagrams discussed so far. It does not describe the functionality of the system but it describes the components used to make those functionalities.
Thus from that point of view, component diagrams are used to visualize the physical components in a system. These components are libraries, packages, files, etc.
Component diagrams can also be described as a static implementation view of a system. Static implementation represents the organization of the components at a particular moment.
A single component diagram cannot represent the entire system but a collection of diagrams is used to represent the whole.
The purpose of the component diagram can be summarized as −
Visualize the components of a system.
Construct executables by using forward and reverse engineering.
Describe the organization and relationships of the components.

UML组件图用于建模面向对象系统的物理方面，这些面向对象系统用于可视化、指定和记录基于组件的系统，还用于通过正向和反向工程构建可执行系统。组件图本质上是一个类图，它关注于一个系统的组件，这些组件通常用于为系统的静态实现视图建模。
组件图在性质和行为方面是不同的。组件图用于对系统的物理方面进行建模。现在的问题是，这些物理方面是什么？物理方面是诸如可执行文件、库、文件、文档等驻留在节点中的元素。
组件图用于可视化系统中组件之间的组织和关系。这些图表也被用来制作可执行系统。
组件图是UML中一种特殊的图。其目的也不同于迄今为止讨论的所有其他图表。它不描述系统的功能，但描述了用于实现这些功能的组件。
因此，从这个角度来看，组件图用于可视化系统中的物理组件。这些组件是库、包、文件等。
组件图也可以描述为系统的静态实现视图。静态实现表示组件在特定时刻的组织。
单个组件图不能代表整个系统，但是使用一组图来表示整个系统。
部件图的用途可概括为–
可视化系统的组件。
使用正向和反向工程构造可执行文件。
描述组件的组织和关系。

1.1.9复合聚合（Composite aggregation）

https://www.uml-diagrams.org/composition.html

Composite aggregation (composition) is a “strong” form of aggregation with the following characteristics:

it is binary association,
it is a whole/part relationship,
a part could be included in at most one composite (whole) at a time, and
if a composite (whole) is deleted, all of its composite parts are “normally” deleted with it.
Note, that UML does not define how, when and specific order in which parts of the composite are created. Also, in some cases a part can be removed from a composite before the composite is deleted, and so is not necessarily deleted as part of the composite.

复合聚合（composition）是一种“强”聚合形式，具有以下特点：
它是二元关联，
这是一种整体/部分关系，
一次最多可以将一个部件包括在一个组合（整体）中，并且
如果删除了一个组合（整体），则其所有组合部分都将“正常”删除。
注意，UML并没有定义如何、何时和特定的顺序来创建组合的各个部分。此外，在某些情况下，可以在删除组合之前从组合中删除零件，因此不必作为组合的一部分删除。

1.1.10具体类(concrete class)

https://www.geeksforgeeks.org/difference-between-abstract-class-and-concrete-class-in-java/

A concrete class in Java is a type of subclass, which implements all the abstract method of its super abstract class which it extends to. It also has implementations of all methods of interfaces it implements.
Java中的一个具体类是一种子类，它实现了它扩展到的超抽象类的所有抽象方法。它还实现了它实现的所有接口方法。

1.1.11基本类型(primitive type)

https://www.uml-diagrams.org/data-type.html

A primitive type is a data type which represents atomic data values, i.e. values having no parts or structure. A primitive data type may have precise semantics and operations defined outside of UML, for example, mathematically.
Standard UML primitive types include:
Boolean,Integer,Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.
A primitive type has the keyword «primitive» above or before the name of the primitive type.

基元类型是表示原子数据值的数据类型，即没有部分或结构的值。一个原始数据类型可能有精确的语义和在UML之外定义的操作，例如，在数学上。
标准UML原语类型包括：
布尔值，整数等。
基元类型的实例没有标识。如果两个实例具有相同的表示，则它们无法区分。
基元类型在基元类型名称的上方或前面有关键字primitive。

1.1.12关联类(association class)

https://www.thoughtco.com/association-2034002#:~:text=The%20association%20relationship%20indicates%20that%20a%20class%20knows,is%20through%20the%20use%20of%20an%20instance%20field.

The association relationship indicates that a class knows about, and holds a reference to, another class. Associations can be described as a “has-a” relationship because the typical implementation in Java is through the use of an instance field. The relationship can be bi-directional with each class holding a reference to the other. Aggregation and composition are types of association relationships.
Associations join one or more of one thing against one or more of another thing. A professor might be associated with a college course (a one-to-one relationship) but also with each student in her class (a one-to-many relationship). The students in one section might be associated with the students in another section of the same course (a many-to-many relationship) while all the sections of the course relate to a single course (a many-to-one relationship).

关联关系表示一个类知道另一个类并持有对另一个类的引用。关联可以被描述为“has-a”关系，因为Java中的典型实现是通过使用实例字段实现的。这种关系可以是双向的，每个类都持有对另一个类的引用。聚合和组合是关联关系的类型。
关联将一个或多个事物与一个或多个另一个事物联系起来。教授可能与大学课程有关（一对一的关系），但也可能与她班上的每个学生（一对多的关系）。一个部分的学生可能与同一课程的另一个部分的学生相关联（多对多关系），而该课程的所有部分都与单个课程相关（多对一关系）。

1.1.13类图(class diagram)

https://www.guru99.com/uml-class-diagram.html#:~:text=Class%20Diagram%20defines%20the%20types%20of%20objects%20in,Methods.%20A%20class%20can%20refer%20to%20another%20class.

UML CLASS DIAGRAM gives an overview of a software system by displaying classes, attributes, operations, and their relationships. This Diagram includes the class name, attributes, and operation in separate designated compartments.
Class Diagram defines the types of objects in the system and the different types of relationships that exist among them. It gives a high-level view of an application. This modeling method can run with almost all Object-Oriented Methods. A class can refer to another class. A class can have its objects or may inherit from other classes.
Class Diagram helps construct the code for the software application development.

UML类图通过显示类、属性、操作和它们之间的关系来提供软件系统的概述。这个图包括类名、属性和操作在不同的指定分区中。
类图定义系统中对象的类型以及它们之间存在的不同类型的关系。它提供了应用程序的高级视图。这种建模方法几乎可以与所有面向对象的方法一起运行。一个类可以引用另一个类。一个类可以有它的对象，也可以从其他类继承。
类图帮助构造软件应用程序开发的代码

1.1.14非功能性需求( Non-functional requirement)

https://www.guru99.com/non-functional-requirement-type-example.html

NON-FUNCTIONAL REQUIREMENT (NFR) specifies the quality attribute of a software system. They judge the software system based on Responsiveness, Usability, Security, Portability and other non-functional standards that are critical to the success of the software system. Example of nonfunctional requirement, “how fast does the website load?” Failing to meet non-functional requirements can result in systems that fail to satisfy user needs.
Non-functional Requirements allows you to impose constraints or restrictions on the design of the system across the various agile backlogs. Example, the site should load in 3 seconds when the number of simultaneous users are > 10000. Description of non-functional requirements is just as critical as a functional requirement.

非功能需求（NFR）规定了软件系统的质量属性。他们根据响应性、可用性、安全性、可移植性和其他非功能性标准来判断软件系统，这些标准对软件系统的成功至关重要。非功能需求的例子，“网站加载速度有多快？“未能满足非功能性需求可能导致系统无法满足用户需求。
非功能性需求允许您在各种敏捷积压工作中对系统的设计施加约束或限制。例如，当并发用户数大于10000时，站点应在3秒内加载。非功能性需求的描述与功能性需求同样重要

1.1.15需求分析(Requirements analysis)

https://www.visual-paradigm.com/guide/requirements-gathering/requirement-analysis-techniques/

Requirement Analysis, also known as Requirement Engineering, is the process of defining user expectations for a new software being built or modified. In software engineering, it is sometimes referred to loosely by names such as requirements gathering or requirements capturing. Requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.

需求分析，也称为需求工程，是定义用户对正在构建或修改的新软件的期望的过程。在软件工程中，它有时被松散地称为需求收集或需求捕获。需求分析包括确定满足新的或变更的产品或项目的需求或条件的任务，考虑到不同涉众的可能冲突的需求，分析、记录、验证和管理软件或系统需求。

1.1.16二元关联(binary association)

https://www.uml-diagrams.org/association-reference.html

Binary association relates two typed instances. It is normally rendered as a solid line connecting two classifiers, or a solid line connecting a single classifier to itself (the two ends are distinct). The line may consist of one or more connected segments.

二进制关联关系两个类型化实例。分类器本身就是一条连接两条线的实体线。直线可以由一个或多个连接的线段组成

1.1.17系统边界(system boundary)

https://www.sciencedirect.com/topics/agricultural-and-biological-sciences/system-boundary

The establishment of system boundaries for an analysis refers to identifying and justifying which aspects of the product life cycle are to be included in a life cycle assessment study (ISO, 2006). Since specific activities and their associated resource use and emission profiles will be of variable importance to the spectrum of potential impact indicators that might be considered in a study, system boundary decisions should, at least in part, be informed by the particular suite of sustainability impacts that are of interest. For studies focusing on potential interactions between nutritional considerations and sustainability impacts (including human health), it will be important to ensure that the system boundaries are established such that all life cycle activities having bearing on one or more of these concerns are included. For example, inclusion of even small inputs of certain pesticides applied in crop agriculture may be unimportant from the perspective of resource use or greenhouse gas emissions, but essential to include for assessment of potential human and ecosystem toxicity impacts. Here, the concept of cut-off criteria in LCA, which refers to established thresholds for exclusion of flows of marginal importance, is particularly significant.

为分析建立系统边界是指确定并证明产品生命周期的哪些方面将被纳入生命周期评估研究（ISO，2006）。由于具体活动及其相关的资源利用和排放概况对研究中可能考虑的潜在影响指标范围具有不同的重要性，因此系统边界的决定至少应部分地由感兴趣的一系列可持续性影响来决定。对于侧重于营养因素和可持续性影响（包括人类健康）之间潜在相互作用的研究，必须确保系统边界的建立，以便包括与一个或多个这些关注点有关的所有生命周期活动。例如，从资源利用或温室气体排放的角度来看，包括在作物农业中使用的某些杀虫剂的哪怕是很小的投入可能并不重要，但对于评估潜在的人类和生态系统毒性影响至关重要。在这里，生命周期评价中的截止标准的概念特别重要，它指的是排除边际重要性流量的既定阈值。

第二次查词

1.2.1系统上下文（System context）

https://www.microtool.de/en/knowledge-base/what-is-the-system-context/

The term system context refers to the environment of your system. A system to be developed never stands on its own but is connected to its environment.
during its development process a number of laws, norms, guidelines and style guides have had an impact on the final design of the system. In reality your might define a requirement for the software that it may be barrier-free, or that it offers support for all current smartphone operating systems. This poses no problem if these elements are included in the system context analysis right at the beginning of a project. Supplementary changes late in the development process result in technical modifications that are difficult to implement and expensive. Maybe an incomplete product has to be marketed and sold.
Apart from the system and its context there is the irrelevant environment which contains everything that has no impact whatsoever on the system and its development.

术语系统上下文是指系统的环境。一个待开发的系统决不是独立存在的，而是与其所处的环境相联系的。
在其发展过程中，一些法律、规范、指南和风格指南对系统的最终设计产生了影响。实际上，你可能会定义一个软件需求，它可能是无障碍的，或者它提供对所有当前智能手机操作系统的支持。如果这些元素在项目开始时就包含在系统上下文分析中，则这不会产生任何问题。开发过程中后期的补充更改会导致技术修改难以实现且成本高昂。也许一个不完整的产品必须被推销和销售。
除了系统及其上下文之外，还有一个无关的环境，它包含了对系统及其开发没有任何影响的所有东西。

1.2.2功能要求（functional requirement）

https://www.guru99.com/functional-requirement-specification-example.html

A Functional Requirement (FR) is a description of the service that the software must offer. It describes a software system or its component. A function is nothing but inputs to the software system, its behavior, and outputs. It can be a calculation, data manipulation, business process, user interaction, or any other specific functionality which defines what function a system is likely to perform. Functional Requirements are also called Functional Specification.
In software engineering and systems engineering, a Functional Requirement can range from the high-level abstract statement of the sender’s necessity to detailed mathematical functional requirement specifications. Functional software requirements help you to capture the intended behaviour of the system.

功能需求（FR）是对软件必须提供的服务的描述。它描述软件系统或其组件。函数只不过是软件系统的输入、行为和输出。它可以是计算、数据操作、业务流程、用户交互，或者定义系统可能执行的功能的任何其他特定功能。功能需求也称为功能规范。
在软件工程和系统工程中，功能需求可以从发送方必要性的高级抽象陈述到详细的数学功能需求规范。功能性软件需求帮助您捕获系统的预期行为。

1.2.3时序图(Sequence diagram)

https://www.smartdraw.com/sequence-diagram/

Sequence diagrams describe interactions among classes in terms of an exchange of messages over time. They’re also called event diagrams. A sequence diagram is a good way to visualize and validate various runtime scenarios. These can help to predict how a system will behave and to discover responsibilities a class may need to have in the process of modeling a new system.

序列图描述了类之间随着时间的消息交换的交互。它们也被称为事件图。序列图是可视化和验证各种运行时场景的好方法。这些可以帮助预测系统的行为，并发现类在建模新系统的过程中可能需要承担的责任。

1.2.4结构化分析(Structured Analysis)

https://www.wisegeek.com/what-is-structured-analysis.htm

The term structured analysis, within the domain of software development, describes the set of techniques used in the design of computer applications. These techniques help explain the required steps within a computer application in a more humanistic manner. The results of a thorough structured analysis and design approach typically describe both the physical and logical layers of the computer application.
Software engineering is a complex process that requires intricate detail on the specifics about how the software application will function. The early pioneers of software engineering realized that this complexity required a method of formality that would not only document the system, but also explain the process in terms that could be understood by the general public. Structured analysis is the process that is used for documenting this complexity.
Structured analysis and design are broken into four primary domains within application architecture. These are the data flows, data models, structure charts, and state models. All of these domains are typically represented in a manner starting from a summary level and progressing into a detail level of interpretation.

软件开发领域的术语结构化分析描述了计算机应用程序设计中使用的一系列技术。这些技术有助于以更人性化的方式解释计算机应用程序中所需的步骤。彻底的结构化分析和设计方法的结果通常描述了计算机应用程序的物理层和逻辑层。软件工程是一个复杂的过程，它需要关于软件应用程序如何运行的细节的复杂细节。软件工程的早期先驱们认识到，这种复杂性需要一种形式化的方法，这种方法不仅可以记录系统，而且可以用一般公众可以理解的术语来解释过程。结构化分析是用来记录这种复杂性的过程。
结构化分析和设计在应用程序体系结构中分为四个主要领域。这些是数据流、数据模型、结构图和状态模型。所有这些领域通常都是以一种方式表示的，即从摘要级别开始，然后进入详细的解释级别

1.2.5行为特征(behavioral feature)

https://www.uml-diagrams.org/common-behaviors.html#:~:text=A%20reception%20is%20behavioral%20feature%20declaring%20that%20a,a%20signal%20and%20specifies%20the%20expected%20behavioral%20response.

A reception is behavioral feature declaring that a classifier is prepared to react to the receipt of a signal. A reception designates a signal and specifies the expected behavioral response. A reception designates a signal and specifies the expected behavioral response.

接收是一种行为特征，表明分类器准备对接收到的信号作出反应。接收指定一个信号并指定预期的行为响应。接收指定一个信号并指定预期的行为响应。

1.2.6通信联系(communication association)

https://www.uml-diagrams.org/use-case-actor-association.html#:~:text=An%20association%20between%20UML%20actor%20and%20a%20use,and%20the%20use%20case%20communicate%
20with%20each%20other.

An association between UML actor and a use case indicates that the actor and the use case communicate with each other. An association between UML actor and a use case indicates that the actor and the use case communicate with each other.

UML参与者和用例之间的关联表示参与者和用例彼此通信。UML参与者和用例之间的关联表示参与者和用例彼此通信。

1.2.7目标模型（Goal model）

https://www.sciencedirect.com/topics/social-sciences/goal-model

Goal Model is a stage model proposing that behavior change is most likely to occur if the target change is compatible with a person’s personal goal structure (what is important to a person and what they want to achieve in life) [14]. According to this model, behavior change is also influenced by the expected consequences of the target behavior, which may be divided into four categories: perceived health costs and benefits, perceived emotional costs and benefits, social influence (expectations of how the social environment might respond to the adoption of the target behavior), and perceived competence. On the other hand, a person’s personal goal structure can be altered by environmental characteristics and personal characteristics, which can act as cues for behavior change.

目标模型是一个阶段模型，提出如果目标改变与一个人的个人目标结构（对一个人来说什么是重要的以及他们希望在生活中实现什么）相一致，行为改变最有可能发生[14]。根据该模型，行为改变还受目标行为预期后果的影响，可分为四类：感知健康成本和收益、感知情感成本和收益、社会影响（对社会环境如何应对目标行为的预期），以及感知能力。另一方面，一个人的目标结构可以被环境特征和个人特征所改变，这些特征可以作为行为改变的线索。

1.2.8容错（fault tolerance）

https://www.techopedia.com/definition/3362/fault-tolerance
Fault tolerance is the way in which an operating system (OS) responds to a hardware or software failure. The term essentially refers to a system’s ability to allow for failures or malfunctions, and this ability may be provided by software, hardware or a combination of both. To handle faults gracefully, some computer systems have two or more duplicate systems.

容错是操作系统（OS）响应硬件或软件故障的方式。这个术语本质上是指系统允许故障或故障的能力，这种能力可以由软件、硬件或两者的组合来提供。为了优雅地处理故障，有些计算机系统有两个或多个重复系统。

1.2.9多重继承(mutiple inheritance)

https://www.uml-diagrams.org/generalization.html

Multiple inheritance is implicitly allowed by UML standard, while the standard provides no definition of what it is.
Classifier in UML can have zero, one or many generalization relationships to more general classifiers. In OOAD multiple inheritance refers to the ability of a class to inherit behaviors and features from more than one superclass.
The origin of multiple inheritance could be in orthogonal taxonomies combined together. For example, the diagram above combines two different classifications of employees - one is based on whether employee is permanent or temporary, and another one is based on the position employee holds.
Though UML standard implicitly allows multiple inheritance, it provides no explicit resolutions or recommendations for well known issues and ambiguities, such as the diamond problem.
In the multiple inheritance diamond problem example above Button class mple, in the Java language profile, generalization of classes should be restricted to single inheritance.

UML标准隐式地允许多重继承，而标准没有提供它的定义。
UML中的分类器可以与更一般的分类器有零、一个或多个泛化关系。在OOAD中，多重继承是指一个类从多个超类继承行为和特性的能力。
多重遗传的起源可能是正交分类法结合在一起。例如，上面的图表结合了两种不同的员工分类——一种是基于员工是永久性的还是临时性的，另一种是基于员工所担任的职位。
虽然UML标准隐式地允许多重继承，但它并没有为众所周知的问题和歧义（如diamond问题）提供明确的解决方案或建议。
在按钮类mpe上面的多重继承菱形问题示例中，在Java语言概要文件中，类的泛化应该限制为单继承。

1.2.10监护条件(guard condition)

https://www.sciencedirect.com/topics/computer-science/guard-condition#:~:text=A%20guard%20condition%20is%20written%20within%20square%20brackets,must%20be%20mutually%20exclusive%2C%20to%20avoid%20nondeterministic%20behavior.

A guard condition is written within square brackets next to the flow. Controlflows in exactly one direction from a decision node, and only follows a flowif the guard condition is true. The guard conditions associated with adecision node must be mutually exclusive, to avoid nondeterministicbehavior.

保护条件写在流旁边的方括号内。控制从一个决策节点正好朝一个方向流动，并且只有在保护条件为真时才跟随一个流。与决策节点相关联的保护条件必须是互斥的，以避免不确定性行为。

1.2.11状态图(statechart diagram)

https://www.guru99.com/state-machine-transition-diagram.html

Statechart diagrams provide us an efficient way to model the interactions or communication that occur within the external entities and a system. These diagrams are used to model the event-based system. A state of an object is controlled with the help of an event.
Statechart diagrams are used to describe various states of an entity within the application system.
There are a total of two types of state machine diagram in UML:
Behavioral state machine
It captures the behavior of an entity present in the system.
It is used to represent the specific implementation of an element.
The behavior of a system can be modelled using behavioral state machine diagram in OOAD.

状态图为我们提供了一种有效的方法来建模外部实体和系统中发生的交互或通信。这些图用于对基于事件的系统进行建模。对象的状态是通过事件来控制的。
状态图用于描述应用程序系统中实体的各种状态。
UML中共有两种类型的状态机图：
行为状态机
它捕获系统中存在的实体的行为。
它用于表示元素的具体实现。
在OOAD中，可以使用行为状态机图对系统的行为进行建模。

1.2.12需求启发（Requirements Elicitation）

https://www.geeksforgeeks.org/software-engineering-requirements-elicitation/

Requirements elicitation is perhaps the most difficult, most error-prone and most communication intensive software development. It can be successful only through an effective customer-developer partnership. It is needed to know what the users really need.
需求启发可能是最困难，最容易出错，最需要交流的软件开发。只有通过有效的客户-开发人员合作关系，它才能成功。需要知道用户的真正需求。
下面列出几个多需求引发方法-
Interviews（面试）
Brainstorming Sessions(头脑风暴会议)
Facilitated Application Specification Technique(便利的应用规范技术（FAST）)
Quality Function Deployment(质量功能部署（QFD）)
Use Case Approach(用例方法)
所使用的启发式技术的成功取决于分析师，开发人员，用户和所涉及客户的成熟度。
1.面试：
进行访谈的目的是从软件中了解客户的期望。
不可能采访每个利益相关者，因此，根据他们的专业知识和信誉从团体中选出代表。
访谈可能是开放式的或结构化的。
在开放式访谈中，没有预设的议程。可能会要求上下文无关的问题来理解该问题。
在结构化访谈中，准备了相当开放的问题的议程。有时会为访谈设计适当的问卷。
2.头脑风暴会议：
这是一项小组技巧
它旨在产生许多新想法，从而提供一个共享观点的平台
需要训练有素的协调员来处理小组偏见和小组冲突。
每个想法都记录在案，以便每个人都能看到。
最后，准备一份文件，其中包括需求列表及其优先级（如果可能）。
3.便利的应用规范技术：目的是弥合期望差距，即开发人员认为应该构建的内容与客户认为要获得的内容之间的差异。
开发了一种面向团队的方法来收集需求。
要求每个与会者列出以下对象的列表：
围绕系统的部分环境
系统产生
系统使用
每个参与者准备他/她的列表，然后合并不同的列表，消除多余的条目，将团队划分为较小的子团队来开发小型规格，最后使用会议的所有输入写下规格草案。
4.质量功能部署：在这种技术中，客户满意度是首要考虑的问题，因此它强调对客户有价值的要求。
确定了3种类型的需求–
正常要求–在此，与客户讨论了所建议软件的目的和目标。示例–结果管理系统的正常要求可能是标记的输入，结果的计算等
预期需求–这些需求是如此明显，以至于客户无需明确声明它们。示例–防止未经授权的访问。
令人兴奋的要求–它包含超出客户期望的功能，并且在存在时证明非常令人满意。示例–当检测到未经授权的访问时，它应备份并关闭所有进程。
此过程涉及的主要步骤是–
确定所有利益相关者，例如 用户，开发人员，客户等
列出客户的所有要求。
指示重要性程度的值被分配给每个需求。
最后，最终的需求清单分类为–
有可能实现
应该推迟，并说明原因
这是不可能实现的，应该放弃
5.用例方法：该技术将文本和图片结合在一起，以更好地理解需求。
用例描述的是系统的“内容”，而不是“如何”。因此，它们仅给出系统的功能视图。
用例设计的组件包括三个主要方面– Actor，用例，用例图。
参与者–是外部代理，它位于系统外部，但以某种方式与其交互。演员可能是人，机器等。它以简笔画表示。演员可以是主要演员或次要演员。
主要参与者–需要系统的协助才能实现目标。
次要参与者–是需要系统帮助的参与者。
用例–它们描述了参与者与系统之间交互的顺序。他们捕获谁（演员）与系统进行什么（交互）。完整的用例集指定了使用系统的所有可能方式。
用例图–用例图以图形方式表示参与者与系统交互时发生的情况。它捕获了系统的功能方面。
简笔画用来代表演员。
椭圆形代表用例。

1.2.13统一塑模语言（Unified modeling language）

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml/

UML, short for Unified Modeling Language, is a standardized modeling language consisting of an integrated set of diagrams, developed to help system and software developers for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.

UML，是Unified Modeling Language（统一建模语言）的缩写，是一种由一组集成图组成的标准化建模语言，旨在帮助系统和软件开发人员指定，可视化，构造和记录软件系统的构件，以及进行业务建模和其他非软件系统。UML代表了一系列最佳工程实践，这些实践已被证明在大型和复杂系统的建模中取得了成功。UML是开发面向对象软件和软件开发过程中非常重要的部分。UML主要使用图形符号来表达软件项目的设计。使用UML可以帮助项目团队进行沟通，探索潜在的设计并验证软件的体系结构设计。

1.2.14需求确认（Requirements Validation）

https://enfocussolutions.com/requirements-verification-and-validation/

验证 是确认需求完整性和正确性的过程。验证还可以确保以下要求：1）实现既定的业务目标； 2）满足涉众的需求； 3）开发人员明确并理解它们。验证对于识别遗漏的需求并确保需求满足某些质量特征至关重要。验证满足每个单独的要求，以确保满足以下条件：
正确 –准确说明客户或外部需求
清晰 –仅具有一种可能的含义
可行 –可以在已知限制内实施
可修改 –可以根据需要轻松更改历史记录
必要 –记录客户真正需要的东西
优先考虑 –在产品中的重要性排名
可追溯 –可以链接到系统需求以及设计，代码和测试
可验证–正确的实施可以通过测试，检查，分析或演示来确定
Verification is the process of confirming that the designed and built product fully addresses documented requirements. Verification consists of performing various inspections, tests, and analyses throughout the product lifecycle to ensure that the design, iterations, and the finished product fully addresses the requirements.
验证是确认设计和制造的产品完全满足书面要求的过程。验证包括在整个产品生命周期中执行各种检查，测试和分析，以确保设计，迭代和最终产品完全满足要求。

1.2.15业务交流（Business Events）

https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/business-events/home-page

Business events provide a mechanism that lets external systems receive notifications from Finance and Operations applications. In this way, the systems can perform business actions in response to the business events.
业务事件提供了一种机制，可以使外部系统从Finance and Operations应用程序接收通知。这样，系统可以响应于业务事件执行业务动作。
Business events occur when a business process is run. During a business process, users who participate in it perform business actions to complete the tasks that make up the business process.
业务事件在运行业务流程时发生。在业务流程中，参与其中的用户将执行业务操作以完成组成业务流程的任务。
A business action that a user performs can be either a workflow action or a non-workflow action. Approval of a purchase requisition is an example of a workflow action, whereas confirmation of a purchase order is an example of a non-workflow action. Both types of actions can generate business events that external systems can use in integration and notification scenarios.
用户执行的业务动作可以是工作流动作，也可以是非工作流动作。批准采购申请是工作流操作的示例，而确认采购订单是非工作流操作的示例。两种类型的操作都可以生成业务事件，外部系统可以在集成和通知场景中使用这些业务事件。

第三次查词作业

1.3.1静态结构（Static Structure）

https://www.webopedia.com/TERM/S/static-data-structure.html

A static data structure is an organization or collection of data in memory that is fixed in size. This results in the maximum size needing to be known in advance, as memory cannot be reallocated at a later point. Arrays are a prominent example of a static data structure.
静态数据结构是一个组织或收集数据在存储器，其被固定在尺寸。这导致需要预先知道最大大小，因为无法在以后重新分配内存。数组是静态数据结构的一个突出示例。
A key advantage of static data structures is that with memory allocation fixed, no control or oversight is needed to prevent potential overflow or underflow issues when adding new items or removing existing ones. This makes static data structures easier to program but at the expense of potential efficiency in terms of memory consumption.
静态数据结构的一个主要优点是，在固定内存分配的情况下，在添加新项或删除现有项时，无需控制或监督即可防止潜在的上溢或下溢问题。这使静态数据结构更易于编程，但以内存消耗方面的潜在效率为代价。
静态数据结构与动态数据结构
Static data structures (SDS) stand in contrast to dynamic data structures (DDS), wherein with the latter the size of the structure can dynamically grow or shrink in size as needed, which provides a programmer with the ability to control exactly how much memory is utilized.
静态数据结构（SDS）与动态数据结构（DDS）相反，动态数据结构（DDS）的大小可以根据需要动态增大或缩小，这为程序员提供了精确控制多少内存的能力。利用。
Static data structures are ideal for storing a fixed number of data items, but they lack the dynamic data structure’s flexibility to consume additional memory if needed or free up memory when possible for improved efficiency.
静态数据结构是存储固定数量数据项的理想选择，但它们缺乏动态数据结构的灵活性，无法根据需要消耗更多的内存，或者在可能的情况下释放内存以提高效率。
Both static and dynamic data structures play a key role in programming languages like C, C++ and Java because they provide the programmer with the option to either focus more on performance in the former case or more on efficient memory consumption in the case of dynamic data structures.
静态数据结构和动态数据结构在C，C ++和Java等编程语言中均起着关键作用，因为它们为程序员提供了选择，使他们可以更专注于前一种情况下的性能，或者更多地关注动态数据结构下的有效内存消耗。

1.3.2需求基线(requirements baseline)

https://www.jamasoftware.com/blog/defining-requirement-baseline/

A requirements baseline is a snapshot in time that represents an agreed-upon, reviewed, and approved set of requirements that have been committed to a specific product release.
That “release” could be a complete delivered product or any interim development increment of the product. When stakeholders “sign off” on requirements, what they’re really doing is agreeing and committing to a specific requirements baseline (whether they think of it in those terms or not).
Once the project team establishes a requirements baseline, the team should follow a pragmatic change control process to make good business and technical decisions about adding newly-requested functionality and altering or deleting existing requirements.
A change control process is not about stifling change; it’s about providing decision-makers with the information that will let them make timely and appropriate decisions to modify the planned functionality. That planned functionality is the baseline.
Typically, a baseline is also given a unique name so that all the project participants can refer to it unambiguously. And good configuration management practices allow the team to reconstruct accurately any previous baseline and all its components.
Whereas the scope definition distinguishes what’s in from what’s out, the requirements baseline explicitly identifies only those requirement specifications that the project will implement. A baseline is not a tangible item but rather a defined list of items. One possible storage location is a software requirements specification (SRS) document.
If that SRS document contains only—and all—the requirements for a specific product release, the SRS constitutes the requirements baseline for the release. However, the SRS document might include additional, lower-priority requirements that are intended for a later release.
Conversely, a large project might need several software, hardware, and interface requirement specifications to fully define the baseline’s components. The goal is to provide the project stakeholders with a clear understanding of exactly what is intended to go into the upcoming release.
Perhaps you’re storing your requirements in a requirements management solution, rather than in documents. In that case, you can define a baseline as a specific subset of the requirements stored in the database that are planned for a given release.
Storing requirements in a solution allows you to maintain an aggregated set of both currently committed requirements and planned future requirements. Some commercial requirements management tools include a baselining function to distinguish those requirements (perhaps even down to the specific version of each requirement) that belong to a certain baseline.
Alternatively, you could define a requirement attribute in the solution to hold the release number or another baseline identifier. Moving a requirement from one baseline to another is then a simple matter of changing the value for that requirement attribute.
The attribute approach will work when each requirement belongs to only a single baseline. However, you might well allocate the same requirement (or different versions of the same requirement) to several baselines if you’re concurrently developing multiple versions of your product, such as home and professional versions. Tool support is essential for such complex baseline management.
When following an incremental or iterative development life cycle, the baseline for each iteration will represent just a fraction of the overall system’s functionality.
A small project my team once worked on took this approach. This project worked in three-week release cycles. For each cycle, the BA specified the software requirements that were to be designed, coded, integrated, and verified during the next three weeks. Each requirements baseline was therefore quite small. In a classic agile approach, the product grew incrementally toward full functionality as the developer periodically released useful versions to the users.

需求基线是一个时间快照，它代表了一组经过商定、评审和批准的需求，这些需求已经提交到特定的产品版本中。
“发布”可以是一个完整的交付产品，也可以是产品的任何临时开发增量。当涉众“签署”需求时，他们真正做的是同意并承诺一个特定的需求基线（不管他们是否用这些术语来考虑）。
一旦项目团队建立了一个需求基线，团队就应该遵循一个实用的变更控制过程来做出关于添加新请求的功能和更改或删除现有需求的良好的业务和技术决策。
变更控制过程并不是要扼杀变更，而是要向决策者提供信息，使他们能够及时做出适当的决策，以修改计划的功能。计划的功能是基线。
通常，基线还被赋予一个唯一的名称，以便所有项目参与者都可以明确地引用它。良好的配置管理实践允许团队准确地重建任何先前的基线及其所有组件。
虽然范围定义区分了输入和输出，但是需求基线只明确地标识了项目将要实现的那些需求规范。基线不是一个有形的项目，而是一个已定义的项目列表。一个可能的存储位置是软件需求规范（SRS）文档。
如果该SRS文档只包含特定产品版本的所有需求，则SRS构成该版本的需求基线。但是，SRS文档可能包含附加的、优先级较低的需求，这些需求将用于以后的版本。
相反，一个大型项目可能需要几个软件、硬件和接口需求规范来完全定义基线的组件。目标是让项目涉众清楚地了解即将发布的版本中的具体内容。
也许您将需求存储在需求管理解决方案中，而不是文档中。在这种情况下，可以将基线定义为数据库中为给定版本计划的需求的特定子集。
在解决方案中存储需求允许您维护当前提交的需求和计划的未来需求的集合。一些商业需求管理工具包括一个基线功能，用来区分那些属于某个基线的需求（甚至可能是每个需求的特定版本）。
或者，您可以在解决方案中定义一个需求属性来保存版本号或另一个基线标识符。然后，将需求从一个基线移动到另一个基线只需更改该需求属性的值。
当每个需求只属于一个基线时，属性方法将起作用。但是，如果您同时开发产品的多个版本，比如家庭版和专业版，您可能会将相同的需求（或同一需求的不同版本）分配给多个基线。工具支持对于这种复杂的基线管理至关重要。
当遵循增量或迭代的开发生命周期时，每次迭代的基线只代表整个系统功能的一小部分。
我的团队曾经在这个小项目上工作过。这个项目在三周的发布周期中工作。对于每个周期，BA规定了在接下来的三周内要设计、编码、集成和验证的软件需求。因此，每个需求基线都非常小。在经典的敏捷方法中，随着开发人员定期向用户发布有用的版本，产品逐渐向完整功能发展。

1.3.3软件需求规范(Requirements specification)

https://www.sciencedirect.com/science/article/pii/B9780123751065000154

the requirements specification, It begins with an illustration of a very general high level procurement process that covers a wide range of procurement situations. At this level it looks as if one process fits all needs, but this is not the case. This chapter describes a number of different cases that cause variations in the process, and information, required. It also illustrates a graph that shows purchase processes for different areas of an Item Volume, Item Value map. The scales on the axes vary depending on the size of the organization, and the place where the lines are drawn may vary for different product categories. A requirement is about something that is needed to exist in the future, as opposed to something in the present or the past. A requirement is usually for a state of functional object—something that has an intended role. Most likely it is for a state of functional system or a state of functional system component. These two are reviewed in the chapter.

采购流程的说明涵盖了一个非常广泛的采购流程。在这个层次上，似乎一个过程可以满足所有需求，但事实并非如此。本章描述了导致过程变化的许多不同情况，以及所需的信息。它还举例说明了一个图表，显示了一个项目量不同领域的采购流程，即项目价值图。坐标轴上的刻度根据组织的大小而变化，线的绘制位置可能因不同的产品类别而异。需求是关于未来存在的东西，而不是现在或过去的东西。需求通常是对功能对象的状态有预期作用的东西。很可能是针对功能系统状态或功能系统组件状态。本章将对这两个问题进行回顾。

1.3.4用例图( Use case diagram)

https://www.guru99.com/use-case-diagrams-example.html

Use Case Diagram captures the system’s functionality and requirements by using actors and use cases. Use Cases model the services, tasks, function that a system needs to perform. Use cases represent high-level functionalities and how a user will handle the system. Use-cases are the core concepts of Unified Modelling language modeling.

用例图通过使用参与者和用例来捕获系统的功能和需求。用例对系统需要执行的服务、任务、功能进行建模。用例表示高级功能以及用户将如何处理系统。用例是统一建模语言建模的核心概念。

1.3.5模型的行为侧重面(behavioral model aspect)

https://behavioralandbrainfunctions.biomedcentral.com/articles/10.1186/s12993-019-0152-4

Aspect oriented development paradigm gives the idea of the separation of concerns. Separation of concerns is not a new idea. Parnas in 1972 gave an idea that a system should be decomposed in modules so that the system should be easy to create, implement, verify and evolve. Each module should hide an aspect of the system that should be evolved independent of the other module. In other words he gave an idea to identify the independent concerns. In the consequence of this research object ori- ented pro gr ammi ng i s de ve loped. These crosscutting concerns are cause of the code tan- gling and code scattering [1]. In code tangling to imple- ment one concern we have to write the code in different modules. In code scattering one piece of code is written in different classes. To address this issue we use aspect- oriented programming. Core concerns can be imple- mented in any object-oriented language. To implement cross cutting concerns we use aspects. Object oriented development paradigm is lacking the idea of separation of concerns [2]. Separation of concerns deals with separating the functio nal properties of the sys- tem from its non-functional properties. Aspect oriented software development is an emerging new programming paradigm. In aspect oriented software development we use the notion of separation of the concerns. There are two major types of concerns when we develop a system; the core concerns and the crosscutting concerns. Core concerns are the functionality provided by the system to be developed. Crosscutting concerns are the concerns like performance, memory management etc. Within aspect oriented development paradigm, there are several programming and modeling facilities avail- able to the developers. There are several programming languages available supporting aspects, e.g., AspecctJ [3], AspectC++, Aspect Oriented C (AspeCt C Development Team, 2007) etc. There is also extensive support of modeling available in aspect oriented development paradigm. In aspect ori- ented development paradigm there are pointcuts, join points, advices, introductions and aspect. A pointcut is a collection of join points. Join point is a well defined point to interact with base classes for example method execution, object initialization, field get or set etc. Ad- vice is a piece of code that executes for the join point for it is defined. Three types of advices are before, after and around. The piece of code in the advices is executed ac-
Using UML Behavioral Model to Support Aspect Oriented Model 99cording to the type o f advice and the join point on which they are defined. These are encapsulated in aspects. As- pect can be abstract or inherited. When we use modeling it provides us the structure for solving the problem, knowledge to find out the multiple solutions, give abstractions to handle complexity, reduce time-to-market for business problem solutions, reduces the development costs, and handle the risk of errors (UML summery V1.1, 1997, UML syntax an d Semantics V1.1, 1997). Benefit of modeling in the aspect oriented development is that aspects are identified at the early stage then they are more reusable and it is also make possible of automated code generation for AOP. Model- ing aspect oriented programs provide the better under- standing of the system. Check the behavior of the as- pect after they are woven into the base class behavioral models is often used [4]. In this research paper, we present an approach for modeling aspect oriented systems. The main contribution of this research paper is to provide a meta-model for as- pect oriented modeling which will show the static and behavioral structure of the aspect. We propose a Meta modeling notation which is for as- pect modeling. We also define how the weaving of as- pect and base classes will be done. We define how the joinpoints are modeled so that they can be weaved the aspect and base class. This extension for aspects will help in representation of how the aspect will interact with the syste

面向方面的开发范式提供了关注点分离的思想。关注点分离并不是一个新概念。Parnas在1972年提出了一个概念，即系统应该被分解成模块，这样系统就应该易于创建、实现、验证和演化。每个模块应该隐藏系统的一个方面，这个方面应该独立于另一个模块来发展。换言之，他提出了确定独立关注点的想法。在这个研究对象的结果下，提出了一些改进方案。这些横切关注点是代码转换和代码分散的原因[1]。在代码纠结中，为了实现一个关注点，我们必须在不同的模块中编写代码。在代码分散中，一段代码是在不同的类中编写的。为了解决这个问题，我们使用面向方面的编程。核心关注点可以在任何面向对象的语言中实现。为了实现横切关注点，我们使用方面。面向对象开发范式缺乏关注点分离的思想[2]。关注点分离是指将系统的功能属性与其非功能属性分离。面向方面软件开发是一种新兴的编程范式。在面向方面的软件开发中，我们使用关注点分离的概念。当我们开发一个系统时，有两种主要的关注点类型：核心关注点和横切关注点。核心关注点是待开发系统提供的功能。横切关注点是诸如性能、内存管理等方面的关注点。在面向方面的开发范式中，有几种编程和建模工具可供开发人员使用。支持方面的编程语言有很多种，例如AspecctJ[3]、AspectC++、面向方面C（Aspect C Development Team，2007）等。面向方面开发范式中也有对建模的广泛支持。面向方面的开发范式包括切入点、连接点、建议、介绍和方面。切入点是连接点的集合。连接点是一个定义良好的与基类交互的点，例如方法执行、对象初始化、字段获取或设置等。Ad-vice是为定义的连接点执行的一段代码。三种类型的建议分别是前、后和前后。通知中的代码段是ac执行的-
根据建议的类型和定义它们的连接点，使用UML行为模型支持面向方面的模型99。这些都封装在方面中。前景可以是抽象的，也可以是继承的。当我们使用建模时，它为我们提供了解决问题的结构，找到多个解决方案的知识，给出处理复杂性的抽象，减少商业问题解决方案的上市时间，降低开发成本，并处理错误的风险（UML summery V1.11997，UML syntax and Semantics V1.11997）。面向方面开发中建模的好处是，在早期阶段就识别出方面，这样就可以更好地重用它们，并且可以为AOP自动生成代码。面向方面程序的模型化提供了对系统更好的理解。在将对象织入基类行为模型后检查它们的行为是经常使用的[4]。在本文中，我们提出了一种面向方面系统的建模方法。本文的主要贡献是面向行为的建模和面向行为的建模。我们提出了一种元建模符号，它是用于面向对象建模的。我们还定义了如何编织类和基类。我们定义如何建模连接点，以便可以将它们编织为方面和基类。方面的这种扩展将有助于表示方面如何与系统交互

1.3.6系统架构（System Architecture）

https://www.wisegeek.com/what-is-system-architecture.htm

The term system architecture is used to describe the overall design and structure of a computer network or system. As information technology has expanded to include a wide range of physical devices, a method is required to organize and connect these items together in a cohesive manner. The term is also used to describe complex computer software tools that include multiple modules.
系统体系结构用于描述计算机网络或系统的总体设计和结构。随着信息技术已经扩展到包括各种各样的物理设备，需要一种以凝聚的方式将这些项目组织和连接在一起的方法。该术语还用于描述包含多个模块的复杂计算机软件工具。
There are four main components to any system architecture: processing power, storage, connectivity, and user experience. The complexity of the system varies widely and is dependent upon user needs, business requirements, funding, and resource availability. It is important to note that system architecture must be flexible and able to meet changing needs quickly. A structure that is too rigid will not be able to accommodate new software or hardware.
任何系统体系结构都有四个主要组件：处理能力，存储，连接性和用户体验。系统的复杂性差异很大，并且取决于用户需求，业务需求，资金和资源可用性。重要的是要注意，系统架构必须灵活并且能够迅速满足不断变化的需求。过于僵化的结构将无法容纳新的软件或硬件。
Processing power is based on the computer or server. This hardware is akin to the brain of the system. Purchasing and installing the correct allocation of processors to the system must be based on the software specifications, number of concurrent users, strength of the connection, and applications. When designing a system, scalability is critical. The system architecture must allow additional processors to be added without any interruption to the current structure.
处理能力取决于计算机或服务器。该硬件类似于系统的大脑。购买和安装正确的处理器分配给系统必须基于软件规格，并发用户数，连接强度和应用程序。在设计系统时，可伸缩性至关重要。系统架构必须允许添加其他处理器，而不会中断当前结构。
Storage space is based on the number and capacity of the hard drives and related devices built into the system. Cost is a determining factor for this type of equipment, as the cost is constantly decreasing as the capacity increases. This is due to ongoing improvements in the production process. However, from an architecture perspective, this adds another element to the process. As the capacity increases, the overall physical shape can change, making equipment obsolete.
存储空间取决于系统中内置的硬盘驱动器和相关设备的数量和容量。成本是此类设备的决定因素，因为随着容量的增加，成本不断降低。这是由于生产过程中的持续改进。但是，从体系结构的角度来看，这为流程增加了另一个元素。随着容量的增加，整体物理形状可能会发生变化，从而使设备过时。
Managing network traffic and connectivity is an important part of the system design. Much like roads in everyday life, the performance of the system is dependent upon correctly sizing and maintaining the connectivity between all aspects of the system. Upgrading network cable, switches, routers, and other equipment is expensive and time consuming, but has a huge impact on system performance.
管理网络流量和连接性是系统设计的重要组成部分。就像日常生活中的道路一样，系统的性能取决于正确确定其大小并保持系统各个方面之间的连通性。升级网络电缆，交换机，路由器和其他设备既昂贵又费时，但对系统性能有巨大影响。
The user experience is based on a combination of system architecture and performance. Business clients typically have minimal understanding or interest in all the aspects of the system that can positively or negatively impact his or her individual computer. A well-designed support system is responsive to users needs and can support the operation in the long run. The responsibility for the overall architecture and support typically falls to the technical operations department.
用户体验基于系统架构和性能的组合。商业客户通常对系统的各个方面都没有什么了解或兴趣，这可能会对他或她的个人计算机产生正面或负面影响。精心设计的支持系统可以响应用户需求，并且可以长期支持操作。总体架构和支持的责任通常属于技术运营部门。

1.3.7通信图(collaboration diagram)

https://www.javatpoint.com/uml-collaboration-diagram

The collaboration diagram is used to show the relationship between the objects in a system. Both the sequence and the collaboration diagrams represent the same information but differently. Instead of showing the flow of messages, it depicts the architecture of the object residing in the system as it is based on object-oriented programming. An object consists of several features. Multiple objects present in the system are connected to each other. The collaboration diagram, which is also known as a communication diagram, is used to portray the object’s architecture in the system.

协作图用于显示系统中对象之间的关系。序列图和协作图表示相同的信息，但不同。它没有显示消息流，而是描述了驻留在系统中的对象的体系结构，因为它是基于面向对象编程的。一个物体由几个特征组成。系统中存在的多个对象相互连接。协作图，也称为通信图，用于描述系统中对象的体系结构。

1.3.8动作(action)

https://alvinalexander.com/java/java-action-abstractaction-actionlistener/

An Action can be used to separate functionality and state from a component. For example, if you have two or more components that perform the same function, consider using an Action object to implement the function.
An Action object is an action listener that provides not only action-event handling, but also centralized handling of the state of action-event-firing components such as tool bar buttons, menu items, common buttons, and text fields. The state that an action can handle includes text, icon, mnemonic, enabled, and selected status.
The most common way an action event can be triggered from multiple places in a Java/Swing application is through the Java menubar (JMenuBar) and toolbar (JToolBar), so in this tutorial I’ll demonstrate how to create your own instances of the AbstractAction class to create easily reusable actions in your Java/Swing applications.

操作可用于将功能和状态与组件分离。例如，如果有两个或多个组件执行同一个功能，请考虑使用动作对象来实现该功能。
动作对象是一个动作侦听器，它不仅提供动作事件处理，而且还集中处理动作事件触发组件（如工具栏按钮、菜单项、常用按钮和文本字段）的状态。操作可以处理的状态包括文本、图标、助记符、启用和选定状态。
在Java/Swing应用程序中，从多个位置触发动作事件的最常见方法是通过Java菜单栏（JMenuBar）和工具栏（JToolBar），因此在本教程中，我将演示如何创建您自己的AbstractAction类实例，以便在Java/Swing应用程序中创建易于重用的操作。

1.3.9行为模型（Behavior model）

https://www.investopedia.com/terms/b/behavioral-modeling.asp#:~:text=Behavioral%20modeling%20means%20using%20available%20and%20relevant%20consumer,also%20used%20in%20marketing%2C%20advertising%2C%20and%20sales%20forecasting.

Behavioral modeling is an approach used by companies to better understand and predict consumer actions. Behavioral modeling uses available consumer and business spending data to estimate future behavior in specific circumstances. Behavioral modeling is used by financial institutions to estimate the risk associated with providing funds to an individual or business and by marketing firms to target advertising. Behavioral economics also relies on behavioral modeling to predict behaviors of agents that fall outside of what would be considered entirely fact-based or rational behavior.

行为建模是公司用来更好地理解和预测消费者行为的一种方法。行为建模使用可用的消费者和企业支出数据来估计特定环境下的未来行为。行为建模被金融机构用来估计与向个人或企业提供资金相关的风险，以及营销公司针对广告的风险。行为经济学还依赖于行为建模来预测行为主体的行为，这些行为不属于完全基于事实或理性的行为。

1.3.10内部转换(internal transition)

http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/transition_xml.html

An internal transition is a way to handle events without leaving a state (or activity) and dispatching its exit or entry actions. You can add an internal transition to a state or activity element.
An internal transition is shorthand for handling events without leaving a state and dispatching its exit or entry actions.

内部转换是一种在不离开状态（或活动）并调度其退出或进入操作的情况下处理事件的方法。可以向状态或活动元素添加内部转换。
内部转换是处理事件而不离开状态并调度其退出或进入操作的简写方法。

1.3.11对象生命线(object lifeline)

https://support.microsoft.com/en-ie/office/object-lifeline-shape-2cd8ab65-36f6-46f1-ac12-3aeb1bd5534b#:~:text=Used%20in%20a%20sequence%20diagram%2C%20an%20object%20lifeline,lifeline%20stops%20or%20starts%20at%20the%20appropriate%20point.

Used in a sequence diagram, an object lifeline represents the existence of an object at a particular time. If the object is created or destroyed during the time period the diagram represents, then the lifeline stops or starts at the appropriate point.

在序列图中，对象生命线表示对象在特定时间的存在。如果对象是在图表所表示的时间段内创建或销毁的，则生命线将在适当的点停止或启动。

1.3.12多重分类(multiple classification)

https://www.r-bloggers.com/2012/12/my-intro-to-multiple-classification-with-random-forests-conditional-inference-trees-and-linear-discriminant-analysis/

a semantic variation of generalization in which an object may belong directly to more than one class

泛化的一种语义变化，其中一个对象可以直接属于一个以上的类。

1.3.13链端点(link end)

http://etutorials.org/Programming/Learning+uml/Part+II+Structural+Modeling/Chapter+3.+Class+and+Object+Diagrams/3.2+Associations+and+Links/

A link object is a specific instance of an association class, and thus has all the characteristics, including structural and behavioral features, defined by the association class. Structural features include attribute values and perhaps other links. Behavioral features include operations and methods, which are shared by all the links of an association class. Whenever an association has a related association class, each of its links has a corresponding link object. This link object defines attribute values for the link’s structural features. In addition, the behavioral features defined by the link’s association class apply to the link objects. In a UML object diagram, a link object is shown as an object rectangle attached by a dashed-line path to its link path in a binary link, or attached to its link diamond in an n-ary link. As with all UML elements representing specific objects or links, link object names should be fully underlined.

链接对象是关联类的特定实例，因此具有由关联类定义的所有特征，包括结构和行为特征。结构特征包括属性值和其他链接。行为特征包括操作和方法，它们由关联类的所有链接共享。每当一个关联有一个相关的关联类时，它的每个链接都有一个相应的链接对象。此链接对象定义链接结构特征的属性值。此外，由link的association类定义的行为特征也适用于link对象。在UML对象图中，链接对象显示为一个对象矩形，在二进制链接中用虚线路径连接到其链接路径，或者在n元链接中连接到其链接菱形。与所有表示特定对象或链接的UML元素一样，链接对象名称应该完全加下划线。

1.3.14状态图(statechart diagram)

https://www.tutorialspoint.com/uml/uml_statechart_diagram.htm

A Statechart diagram describes a state machine. State machine can be defined as a machine which defines different states of an object and these states are controlled by external or internal events.
it is a special kind of a Statechart diagram. As Statechart diagram defines the states, it is used to model the lifetime of an object.
Statechart diagram is one of the five UML diagrams used to model the dynamic nature of a system. They define different states of an object during its lifetime and these states are changed by events. Statechart diagrams are useful to model the reactive systems. Reactive systems can be defined as a system that responds to external or internal events.
Statechart diagram describes the flow of control from one state to another state. States are defined as a condition in which an object exists and it changes when some event is triggered. The most important purpose of Statechart diagram is to model lifetime of an object from creation to termination.
Statechart diagrams are also used for forward and reverse engineering of a system. However, the main purpose is to model the reactive system.
Following are the main purposes of using Statechart diagrams：
To model the dynamic aspect of a system.
To model the life time of a reactive system.
To describe different states of an object during its life time.
Define a state machine to model the states of an object.

状态图描述状态图。这些状态可以定义为一台机器的外部状态，这些状态可以定义为一台机器的不同状态。
它是一种特殊的状态图。由于状态图定义了状态，所以它被用来建模对象的生存期。
状态图是用于建模系统动态特性的五种UML图之一。它们定义了一个对象在其生命周期内的不同状态，这些状态会因事件而改变。状态图有助于对反应系统进行建模。反应性系统可以定义为对外部或内部事件做出响应的系统。
状态图描述从一个状态到另一个状态的控制流。状态被定义为对象存在的条件，当某个事件被触发时，它会发生变化。状态图最重要的目的是建模对象从创建到终止的生命周期。
状态图也可用于系统的正向和反向工程。然而，主要目的是对无功系统进行建模。
以下是使用状态图的主要目的：
对系统的动态方面进行建模。
对反应系统的寿命进行建模。
描述一个物体在其生命周期中的不同状态。
定义一个状态机来为对象的状态建模

1.3.15状态机模型（State Machine Models）

https://www.techopedia.com/definition/16447/state-machine

A state machine is a concept used in designing computer programs or digital logic. There are two types of state machines: finite and infinite state machines. The former is comprised of a finite number of states, transitions, and actions that can be modeled with flow graphs, where the path of logic can be detected when conditions are met. The latter is not practically used.
状态机是用于设计计算机程序或数字逻辑的概念。状态机有两种类型：有限状态机和无限状态机。前者由有限数量的状态，转换和动作组成，可以通过流程图建模，在满足条件时可以在其中检测逻辑路径。后者实际上没有使用。
A state machine is any device storing the status of something at a given time. The status changes based on inputs, providing the resulting output for the implemented changes. A finite state machine has finite internal memory. Input symbols are read in a sequence producing an output feature in the form of a user interface.
状态机是在给定时间存储某些状态的任何设备。状态根据输入而变化，为实现的变化提供结果输出。有限状态机具有有限的内部存储器。按顺序读取输入符号，以用户界面的形式生成输出功能。
State machines are represented using state diagrams. The output of a state machine is a function of the input and the current state. State machines play a significant role in areas such as electrical engineering, linguistics, computer science, philosophy, biology, mathematics, and logic. They are best used in the modeling of application behavior, software engineering, design of hardware digital systems, network protocols, compilers, and the study of computation and languages.
状态机使用状态图表示。状态机的输出是输入和当前状态的函数。状态机在电气工程，语言学，计算机科学，哲学，生物学，数学和逻辑学等领域中发挥着重要作用。它们最适合用于应用程序行为建模，软件工程，硬件数字系统设计，网络协议，编译器以及计算和语言研究。
The operation of a state machine begins from a start state. On a successful transition it ends up in an accept state. The transition takes place based on the inputs provided. The current state depends on the past state of the system. The number of states formed depends on the available states of memory. A transition is enabled based on certain conditions and indicates a state change. An action describes an activity performed at the given moment. The different types of actions are transition action, input action, entry action, and exit action.
状态机的操作从启动状态开始。成功转换后，它将最终处于接受状态。过渡基于提供的输入进行。当前状态取决于系统的过去状态。形成的状态数取决于存储器的可用状态。根据某些条件启用过渡，并指示状态变化。动作描述了在给定时刻执行的活动。动作的不同类型是过渡动作，输入动作，进入动作和退出动作。
Deterministic automata have exactly one transition in every state for each possible input. In non-deterministic automata, a state input leads to one, many, or no transitions. A state machine with only one state is called a combinatorial state machine and uses only input actions.
确定性自动机在每种状态下对于每种可能的输入都只有一个过渡。在非确定性自动机中，状态输入导致一个，多个或没有转换。仅具有一个状态的状态机称为组合状态机，并且仅使用输入操作。
The two different groups of state machines are acceptors and transducers. Acceptors produce a binary output, based on whether the input is accepted or rejected by the machine. While processing the input, if the current state is accepting, the input is accepted. Otherwise it is rejected. Languages accepted by state machines are called regular languages. Start states are represented by an arrow pointing on it from anywhere, while accepted states are represented using double circles. Transducers cater output based on a given input, using actions. Moore and Mealy machines are examples of transducers.
两组不同的状态机是接收器和传感器。接受器根据机器是否接受输入来产生二进制输出。在处理输入时，如果当前状态正在接受，则接受输入。否则将被拒绝。状态机接受的语言称为常规语言。起始状态由从任何地方指向其的箭头表示，而接受状态则由双圆圈表示。换能器使用动作根据给定的输入满足输出。Moore和Mealy机器是换能器的示例。
Unmodified modeling language state machines are also widely used as they have both the Moore and Mealy machine characteristics within them. They include additional concepts such as orthogonal regions and hierarchically-nested states.
未修改的建模语言状态机还具有Moore和Mealy机器特性，因此也被广泛使用。它们包括其他概念，例如正交区域和分层嵌套状态。

第四次查词作业

1.4.1互动流程图（Interactive Flow Diagram）

https://www.conceptdraw.com/How-To-Guide/what-is-interactive-flowcharts

交互式流程图可以改变人们创建和组织其社交媒体响应过程的方式。ConceptDraw DIAGRAM提供了开发可与Action Mind Maps连接的响应流程图的工具。通过响应过程的各个阶段进行可视导航，可以帮助您找到要通过“行动思维导图”执行的特定行动。动作思维导图可用于描述主要消息和好的补充内容，显示消息示例，还可以定义特定情况下消息传递的主要目标。

1.4.2平台独立模型（Platform Independent Models）

https://www.igi-global.com/chapter/transformation-of-platform-independent-model-into-platform-specific-model-in-model-driven-architecture/96615

PIM，是Platform Independent Model的缩写，即平台独立模型。
平台独立模型是一个软件模型或业务系统，它独立于实现它的特定技术平台，例如，明确地程序设计语言，操作系统或数据库。
PIM通常应用在MDA(Model Driven Architecture，模型驱动架构)方法中。MDA方法是模型驱动工程(Model Driven ngineering)的OMG(国际对象组织)实现版本。它的主要思路是能够使用MTL(Model Translation Language，模型转换语言)实现从PIM到PSM(Platform-specific Model，平台相关模型)的转换。可以使用一种兼容最新QVT(查询/视图/转换)标准的语言来实现，比如VIATRA(Visual Automated Model TRAnsformations，可视化自动转换模型)或者ATL(ATLAS Transformation Language)来实现。

1.4.3业务交流（Business Events）

https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/business-events/home-page

Business events provide a mechanism that lets external systems receive notifications from Finance and Operations applications. In this way, the systems can perform business actions in response to the business events.

业务事件提供了一种机制，可以使外部系统从Finance and Operations应用程序接收通知。这样，系统可以响应于业务事件执行业务动作。

Business events occur when a business process is run. During a business process, users who participate in it perform business actions to complete the tasks that make up the business process.

业务事件在运行业务流程时发生。在业务流程中，参与其中的用户将执行业务操作以完成组成业务流程的任务。
A business action that a user performs can be either a workflow action or a non-workflow action. Approval of a purchase requisition is an example of a workflow action, whereas confirmation of a purchase order is an example of a non-workflow action. Both types of actions can generate business events that external systems can use in integration and notification scenarios.
用户执行的业务动作可以是工作流动作，也可以是非工作流动作。批准采购申请是工作流操作的示例，而确认采购订单是非工作流操作的示例。两种类型的操作都可以生成业务事件，外部系统可以在集成和通知场景中使用这些业务事件。

1.4.4存储库模式（The Repository Pattern）

https://deviq.com/repository-pattern/

The Repository Pattern has gained quite a bit of popularity since it was first introduced as a part of Domain-Driven Design in 2004. Essentially, it provides an abstraction of data, so that your application can work with a simple abstraction that has an interface approximating that of a collection. Adding, removing, updating, and selecting items from this collection is done through a series of straightforward methods, without the need to deal with database concerns like connections, commands, cursors, or readers. Using this pattern can help achieve loose coupling and can keep domain objects persistence ignorant. Although the pattern is very popular (or perhaps because of this), it is also frequently misunderstood and misused. There are many different ways to implement the Repository pattern. Let’s consider a few of them, and their merits and drawbacks.
自从2004年作为领域驱动设计的一部分首次引入存储库模式以来，它已经获得了相当大的欢迎。从本质上讲，它提供了数据的抽象，因此您的应用程序可以使用接口近似的简单抽象来工作。一个集合。通过一系列简单的方法可以从此集合中添加，删除，更新和选择项目，而无需处理连接，命令，游标或阅读器之类的数据库问题。使用此模式可以帮助实现松散耦合，并使域对象的持久性忽略。尽管这种模式非常流行（或者正因为如此），但它也经常被误解和滥用。有许多不同的方法来实现存储库模式。让我们考虑其中的一些，以及它们的优缺点。
Repository Per Entity or Business Object每个实体或业务对象的存储库
The simplest approach, especially with an existing system, is to create a new Repository implementation for each business object you need to store to or retrieve from your persistence layer. Further, you should only implement the specific methods you are calling in your application. Avoid the trap of creating a “standard” repository class, base class, or default interface that you must implement for all repositories. Yes, if you need to have an Update or a Delete method, you should strive to make its interface consistent (does Delete take an ID, or does it take the object itself?), but don’t implement a Delete method on your Look up Table Repository that you’re only ever going to be calling List() on. The biggest benefit of this approach is YAGNI – you won’t waste any time implementing methods that never get called.
最简单的方法，特别是对于现有系统，是为需要存储到持久层或从持久层检索的每个业务对象创建一个新的存储库实现。此外，您应该只实现在应用程序中调用的特定方法。避免创建必须为所有存储库实现的“标准”存储库类、基类或默认接口的陷阱。是的，如果您需要一个Update或Delete方法，您应该努力使它的接口一致（Delete接受ID，还是接受对象本身？），但不要在查找表存储库中实现只调用List（）的Delete方法。这种方法的最大好处是YAGNI—您不会浪费任何时间实现从未被调用的方法。

1.4.5异步动作(asynchronous action)

https://www.codeguru.com/csharp/.net/net_asp/mvc/creating-asynchronous-actions-in-asp.net-mvc.htm#:~:text=Asynchronous%20actions%20allow%20you%20to%20handle%20more%20concurrent,how%20to%20create%20them%20in%20an%20ASP.NET%20MVC.

Asynchronous actions allow you to handle more concurrent requests and can be implemented using async / await keywords. Asynchronous actions are useful in situations where you are performing some network operation such as calling a remote service.

异步操作允许处理更多的并发请求，并且可以使用async/await关键字来实现。异步操作在执行某些网络操作（如调用远程服务）的情况下非常有用。

1.4.6序列图(sequence diagram)

https://creately.com/blog/diagrams/sequence-diagram-tutorial/

Sequence diagrams, commonly used by developers, model the interactions between objects in a single use case. They illustrate how the different parts of a system interact with each other to carry out a function, and the order in which the interactions occur when a particular use case is executed.
In simpler words, a sequence diagram shows different parts of a system work in a ‘sequence’ to get something done.

开发人员通常使用序列图，在单个用例中对对象之间的交互进行建模。它们说明了系统的不同部分是如何相互作用以实现功能的，以及在执行特定用例时交互发生的顺序。
简单地说，序列图显示了一个系统的不同部分按照“顺序”工作来完成某件事情。

1.4.7建模语言(Modeling language)

https://www.techopedia.com/definition/20810/modeling-language

Modeling language is any graphical or textual computer language that provisions the design and construction of structures and models following a systematic set of rules and frameworks.
Modeling language is part of and similar to artificial language.
Modeling language is mainly used in the field of computer science and engineering for designing models of new software, systems, devices and equipment. The context of modeling language is primarily textual and graphical, but based on the requirements and specific domain in use, modeling languages fall into the following four categories:
System modeling language
Object modeling languages
Virtual reality modeling language
Data modeling language
Unified modeling language (UML) is a popular modeling language that is used to build system and object models graphically.
Language models determine word probability by analyzing text data. They interpret this data by feeding it through an algorithm that establishes rules for context in natural language. Then, the model applies these rules in language tasks to accurately predict or produce new sentences. The model essentially learns the features and characteristics of basic language and uses those features to understand new phrases.
There are several different probabilistic approaches to modeling language, which vary depending on the purpose of the language model. From a technical perspective, the various types differ by the amount of text data they analyze and the math they use to analyze it. For example, a language model designed to generate sentences for an automated Twitter bot may use different math and analyze text data in a different way than a language model designed for determining the likelihood of a search query.

建模语言是任何图形化或文本化的计算机语言，它根据一套系统的规则和框架来设计和构造结构和模型。
建模语言是人工语言的一部分，与人工语言相似。
建模语言主要用于计算机科学和工程领域，用于设计新的软件、系统、设备和设备的模型。建模语言的上下文主要是文本和图形，但根据需求和使用的特定领域，建模语言分为以下四类：
系统建模语言
对象建模语言
虚拟现实建模语言
数据建模语言
统一建模语言（UML）是一种流行的建模语言，用于图形化地建立系统和对象模型。
语言模型通过分析文本数据来确定单词的概率。他们通过一种算法来解释这些数据，该算法用自然语言建立上下文规则。然后，该模型将这些规则应用到语言任务中，以准确地预测或生成新的句子。该模型本质上是学习基本语言的特征和特征，并利用这些特征来理解新短语。
有几种不同的概率方法来建模语言，这取决于语言模型的目的。从技术的角度来看，不同类型的文本数据不同，它们所分析的文本数据量和用于分析的数学方法不同。例如，为自动Twitter机器人生成句子而设计的语言模型可能使用不同的数学方法和分析文本数据的方式与用于确定搜索查询可能性的语言模型不同。

1.4.8性能要求(Performance requirement)

https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/performance/doc_perf_reqs.html

In identifying and quantifying performance requirements, it is important to identify the reasoning behind a particular requirement. This is part of the general capacity planning process. Users might be basing their statements of requirements on assumptions about the logic of the program that do not match the programmer’s assumptions.

At a minimum, a set of performance requirements should document the following:
The maximum satisfactory response time to be experienced most of the time for each distinct type of user-computer interaction, along with a definition of most of the time. Response time is measured from the time that the user performs the action that says “Go” until the user receives enough feedback from the computer to continue the task. It is the user’s subjective wait time. It is not from entry to a subroutine until the first write statement.
If the user denies interest in response time and indicates that only the result is of interest, you can ask whether “ten times your current estimate of stand-alone execution time” would be acceptable. If the answer is “yes,” you can proceed to discuss throughput. Otherwise, you can continue the discussion of response time with the user’s full attention.

The response time that is minimally acceptable the rest of the time. A longer response time can cause users to think the system is down. You also need to specify rest of the time; for example, the peak minute of a day, 1 percent of interactions. Response time degradations can be more costly or painful at a particular time of the day.
The typical throughput required and the times it will be taking place. This is not a casual consideration. For example, the requirement for one program might be that it runs twice a day: at 10:00 a.m. and 3:15 p.m. If this is a CPU-limited program that runs for 15 minutes and is planned to run on a multiuser system, some negotiation is in order.
The size and timing of maximum-throughput periods.
The mix of requests expected and how the mix varies with time.
The number of users per machine and total number of users, if this is a multiuser application. This description should include the times these users log on and off, as well as their assumed rates of keystrokes, completed requests, and think times. You may want to investigate whether think times vary systematically with the preceding and following request.
Any assumptions that the user is making about the machines the workload will run on. If the user has a specific existing machine in mind, make sure you know that early on. Similarly, if the user is assuming a particular type, size, cost, location, interconnection, or any other variable that will constrain your ability to satisfy the preceding requirements, that assumption also becomes part of the requirements. Satisfaction will probably not be assessed on the system where the program is developed, tested, or first installed.

在识别和量化性能需求时，确定特定需求背后的推理是很重要的。这是总体容量规划过程的一部分。用户的需求陈述可能是基于程序逻辑的假设，而这些假设与程序员的假设不符。
一套性能要求至少应记录以下内容：
对于每种不同类型的用户-计算机交互，在大多数时间内所经历的最大令人满意的响应时间，以及大多数时间的定义。响应时间是从用户执行“执行”操作的时间开始计算的，直到用户从计算机收到足够的反馈以继续执行任务。它是用户的主观等待时间。在第一个write语句之前，它不是从入口到子例程的。
如果用户否认对响应时间感兴趣，并指出只有结果感兴趣，那么您可以询问“十倍于当前估计的独立执行时间”是否可以接受。如果答案是“是”，您可以继续讨论吞吐量。否则，您可以继续讨论响应时间，让用户全神贯注。
其余时间内可接受的最小响应时间。较长的响应时间会导致用户认为系统已关闭。您还需要指定其余时间；例如，一天中的高峰分钟，交互的1%。在一天中的某个特定时间，响应时间的降低可能更昂贵或更痛苦。
所需的典型吞吐量及其发生的时间。这不是一个偶然的考虑。例如，对一个程序的要求可能是一天运行两次：上午10:00和下午3:15。如果这是一个CPU有限的程序，运行时间为15分钟，计划在多用户系统上运行，则需要进行一些协商。
最大吞吐量周期的大小和时间。
预期的请求组合以及组合如何随时间变化。
每台机器的用户数和用户总数（如果这是多用户应用程序）。这个描述应该包括这些用户登录和注销的时间，以及他们假定的击键率、完成的请求和思考时间。您可能需要调查思考时间是否随前一个请求和后一个请求而有系统地变化。
用户对运行工作负载的机器所做的任何假设。如果用户想要一台特定的现有机器，请确保尽早知道这一点。类似地，如果用户假设某个特定的类型、尺寸、成本、位置、互连或任何其他变量将限制您满足上述要求的能力，则该假设也将成为需求的一部分。在开发、测试或首次安装程序的系统上，可能不会评估满意度。

1.4.9需求工程(Requirements Engineering)

Requirements engineering is the process of conforming engineering designs to a set of core software requirements. This is critically important for creating accurate results in software engineering.

Requirements engineering is also known as requirements analysis.
In requirements engineering, engineers look at a set of data pertaining to the goals and objectives of the software: how it will work and what are the qualities of the properties it must have to provide the results needed. Engineers then work forward from these data to look at specific coding solutions that support these results. Elements of requirements engineering include:

Requirements solicitation, where a software company gets the requirements from a client
Requirements analysis
Requirements specification
Requirements verification, where engineers confirm that the requirements are accurate
Requirements management, which matches processes to their requirements
It is important to point out that a major part of requirements engineering has to do with the stakeholders or parties involved in the process. Typically, developers from a software company tailor the software requirements according to the needs of the client. That means that many stages of requirements engineering happen during the communications between the client and the software company.

IT experts have pointed out how requirements engineering remains a significant challenge for companies, partly because of the ambiguous nature of software development, the challenge of getting accurate requirements from a client, and the ongoing process of matching internal processes at a development company to the goals and objectives of an outside client. In other words, requirements engineering attempts to bridge that divide between what the client and what the developers are thinking, and to create a solid, consistent framework for the actual construction of sophisticated software products.

需求工程是将工程设计符合一组核心软件需求的过程。这对于在软件工程中创建准确的结果至关重要。
需求工程也称为需求分析。
在需求工程中，工程师关注一组与软件的目标和目标相关的数据：它将如何工作，它必须具备哪些属性才能提供所需的结果。然后，工程师根据这些数据进一步研究支持这些结果的特定编码解决方案。需求工程的要素包括：
需求征集，软件公司从客户那里获得需求
需求分析
需求规范
需求验证，工程师确认需求是准确的
需求管理，将过程与需求相匹配
需要指出的是，需求工程的主要部分与过程中涉及的涉众或各方有关。通常，软件公司的开发人员会根据客户的需求定制软件需求。这意味着需求工程的许多阶段都发生在客户和软件公司之间的通信过程中。
IT专家指出，需求工程对公司来说仍然是一个重大的挑战，部分原因是软件开发的模糊性，即从客户那里获得准确的需求，以及将开发公司的内部流程与外部客户的目标匹配的持续过程。换句话说，需求工程试图弥合客户和开发人员的想法之间的鸿沟，并为复杂软件产品的实际构建创建一个坚实、一致的框架。

1.4.10状态机(State machine)

https://www.smashingmagazine.com/2018/01/rise-state-machines/

A state machine is a mathematical model of computation. It’s an abstract concept whereby the machine can have different states, but at a given time fulfills only one of them. There are different types of state machines. The most famous one, I believe, is the Turing machine. It is an infinite state machine, which means that it can have a countless number of states. The Turing machine does not fit well in today’s UI development because in most cases we have a finite number of states. This is why finite state machines, such as Mealy and Moore, make more sense.

The difference between them is that the Moore machine changes its state based only on its previous state. Unfortunately, we have a lot of external factors, such as user interactions and network processes, which means that the Moore machine is not good enough for us either. What we are looking for is the Mealy machine. It has an initial state and then transitions to new states based on input and its current state.

One of the easiest ways to illustrate how a state machine works is to look at a turnstile. It has a finite number of states: locked and unlocked. Here is a simple graphic that shows us these states, with their possible inputs and transitions.
The initial state of the turnstile is locked. No matter how many times we may push it, it stays in that locked state. However, if we pass a coin to it, then it transitions to the unlocked state. Another coin at this point would do nothing; it would still be in the unlocked state. A push from the other side would work, and we’d be able to pass. This action also transitions the machine to the initial locked state.

If we wanted to implement a single function that controls the turnstile, we would probably end up with two arguments: the current state and an action. And if you use Redux, this probably sounds familiar to you. It is similar to the well-known reducer function, where we receive the current state, and based on the action’s payload, we decide what will be the next state. The reducer is the transition in the context of state machines. In fact, any application that has a state that we can somehow change may be called a state machine. It’s just that we are implementing everything manually over and over again.

状态机是计算的数学模型。这是一个抽象的概念，机器可以有不同的状态，但在给定的时间内只能实现其中一个状态。有不同类型的状态机。我相信，最著名的是图灵机器。它是一个无限状态机，这意味着它可以有无数个状态。图灵机器并不适合今天的UI开发，因为在大多数情况下，我们的状态是有限的。这就是为什么像Mealy和Moore这样的有限状态机更有意义。
它们之间的区别在于摩尔机器只根据先前的状态改变状态。不幸的是，我们有很多外部因素，比如用户交互和网络进程，这意味着摩尔机器对我们来说也不够好。我们要找的是粉状机器。它有一个初始状态，然后根据输入和当前状态转换到新状态。
说明状态机如何工作的最简单方法之一是查看旋转栅门。它有有限数量的状态：锁定和解锁。这是一个简单的图形，显示了这些状态，以及它们可能的输入和转换。
旋转栅门的初始状态是锁定的。不管我们推多少次，它都会保持锁定状态。但是，如果我们向它传递一个硬币，那么它就会转换到解锁状态。在这一点上，另一枚硬币不会起任何作用；它仍然处于解锁状态。从另一边推一下就行了，我们就能通过了。此操作还将机器转换到初始锁定状态。
如果我们想实现一个控制旋转栅门的函数，我们可能会得到两个参数：当前状态和一个操作。如果你使用Redux，这可能听起来很熟悉。它类似于众所周知的reducer函数，我们接收当前状态，并根据动作的有效载荷来决定下一个状态。reducer是状态机上下文中的转换。事实上，任何具有我们可以以某种方式更改的状态的应用程序都可以称为状态机。只是我们一次又一次地手动执行所有的操作。

1.4.11抽象(abstraction)

https://www.geeksforgeeks.org/abstraction-in-java-2/

Data Abstraction is the property by virtue of which only the essential details are displayed to the user.The trivial or the non-essentials units are not displayed to the user. Ex: A car is viewed as a car rather than its individual components.

Data Abstraction may also be defined as the process of identifying only the required characteristics of an object ignoring the irrelevant details.The properties and behaviors of an object differentiate it from other objects of similar type and also help in classifying/grouping the objects.

Consider a real-life example of a man driving a car. The man only knows that pressing the accelerators will increase the speed of car or applying brakes will stop the car but he does not know about how on pressing the accelerator the speed is actually increasing, he does not know about the inner mechanism of the car or the implementation of accelerator, brakes etc in the car. This is what abstraction is.

In java, abstraction is achieved by interfaces and abstract classes. We can achieve 100% abstraction using interfaces.

数据抽象是仅向用户。那个不向用户显示琐碎或非基本单元。例：汽车被看作是一辆汽车，而不是它的单个部件。
数据抽象也可以定义为只识别对象的所需特征而忽略不相关的过程详细信息对象的属性和行为将其与其他类似类型的对象区分开来，也有助于对对象进行分类/分组。
考虑一个现实生活中一个男人开车的例子。这个人只知道踩油门会提高汽车的速度或踩下刹车会使汽车停下来，但他不知道踩油门后速度实际上是如何增加的，他不知道汽车的内部机制，也不知道汽车中加速器、制动器等的执行情况。这就是抽象。
在java中，抽象是通过接口和抽象类来实现的。我们可以使用接口实现100%的抽象。

1.4.12动作序列(action sequence)

https://cn.bing.com/search?q=action+sequence+java&qs=n&form=QBRE&sp=-1&pq=&sc=0-0&sk=&cvid=58A9D4B246DD438FA0F5E9B624805009

Action sequences are a unique and powerful feature of the Pentaho BI Platform; they enable BI developers and business users to perform advanced tasks that cannot easily be accomplished through Pentaho’s design tools and user interface functions, including interaction with third-party software frameworks. the Action Sequence Editor built into Pentaho Design Studio.An action sequence is an XML document that defines an ordered set of action definitions that together perform a single task; it is the smallest complete task that the Pentaho BI Platform’s solution engine can perform. It is useful for sequencing small, linear, success-oriented tasks like reporting and bursting,and has the ability to loop through a result set, call other action sequences, and conditionally execute components.
Action sequences can be created through raw XML (though the DOM for each component can be unique),
or through the graphical interface built into Design Studio (though not every function in every component is supported).

动作序列是Pentaho BI平台的一个独特而强大的特性；它们使BI开发人员能够使用
以及业务用户执行无法通过Pentaho轻松完成的高级任务设计工具和用户界面功能，包括与第三方软件框架的交互。操作序列是一个XML文档，它定义了一组有序的动作定义，这些定义集合在一起执行单个任务；这是Pentaho BI平台解决方案引擎完成的最小任务
可以表演。它对于排序小的、线性的、面向成功的任务非常有用，比如报告和突发事件，
并且能够遍历结果集、调用其他操作序列并有条件地执行组件。
动作序列可以通过原始XML创建（尽管每个组件的DOM可以是唯一的），
或者通过designstudio内置的图形界面（尽管不是每个组件中的每个功能都是支持）。

1.4.13需求文档（Requirements document）

https://www.scalablepath.com/blog/how-to-write-an-effective-product-requirements-document/

产品需求文档内容可包括：
Goals（目标）：业务目标和目的作为背景，向开发人员团队展示了他们为什么要构建自己正在构建的东西。
User Personas（用户角色）：用户角色是与您所需或实际受众匹配的假设人员。考虑这些用户的背景将提高您创建满足其需求的产品的能力。
User Stories（用户故事）：用户案例是对功能的简短描述，从您新创建的最终用户个人资料之一的角度讲述。
Page List（页面清单）：定义了主要的用户故事后，您应该对应用程序将拥有的页面或屏幕有一个扎实的想法。页面列表（或站点地图）是对此进行记录的第一步。
Page Descriptions（页面说明）：一旦获得了应用程序中所有页面或屏幕的列表，就可以进行下一步并定义每个页面上的内容。为每个页面上包含的主要项目制作一个简单的编号列表，并将最重要的项目放在列表的顶部（这将传达每个项目的相对重要性，这将对设计有所帮助）。
Write frames（线框（可选）)：线框是简单的页面布局，概述了元素，页面上的要素的大小和位置。它们通常没有颜色，字体样式，徽标或任何设计元素。
Non-Functional Requirements（非功能性要求）：产品需求文档的大部分定义了软件的运行方式（功能需求），而文档的这一部分定义了对您的业务可能很重要的需求，但与软件本身的运行方式无关。在这里，您可以交流开发人员需要考虑的任何特殊参数。
Risks（风险性）：如果项目面临任何重大的已知风险，最好将其记录下来。通常，对于开发团队来说，首先尝试解决软件项目中的风险部分是一个好主意，这样，如果某个特定功能不可行，您就可以在投入过多时间和金钱之前就早知道。
Future Iterations（未来的迭代）：在编写产品需求文档时，您应该不断思考“这对于我的MVP绝对必要吗？” 。如果某个功能是一个好主意，并且对业务的长期计划很重要，但是没有将其纳入MVP，则应在以后的“迭代”部分中简要记录该功能，以免被遗忘，并且开发人员可以确保将来可以扩展该应用程序以支持这些关键功能。

1.4.14互动模型（Interaction Models）

https://boxesandarrows.com/interaction-modeling/

交互建模是使用工具识别和定位可用性问题的好方法。存在几种方法（有关技术综述，请参见Olson＆Olson 1990）。建模技术具有规范性，因为它们旨在捕获用户可能会做的事情，而不是描述用户实际做了什么。
大多数方法（描述性或说明性）都无法将用户行为与认知过程之间的关系纳入其中。例如，认知处理模型可能会尝试解释特定任务在心理上如何或为何如此困难，但是该困难并不直接与可观察到的用户动作有关。相反，诸如路径度量，点击流分析和面包屑跟踪之类的描述性技术很少或根本不考虑导致这些用户动作的认知过程。
动作与认知过程之间的关系很重要，因为它可以解释用户的行为并转化为良好设计解决方案的支持性论据。说明性技术和描述性技术对于表征认知过程和用户​​动作（齿轮动作）关系都是必需的。
收集和报告用户数据而不显示齿轮作用关系会导致不良的问题定义。实际上，从业人员通常不会在观察到的用户行为与存在问题的主张之间呈现任何关系。可用性问题以用户口头陈述的形式出现，例如“我不知道该怎么办。” 尽管存在用户进入此明显不确定状态的认知原因，但很少提出该原因。此外，通常不提供已识别问题和解决该问题的解决方案之间的关系。如果我们不知道为什么行为会成为问题，我们就无法设计一个好的解决方案。
一种由三部分组成的交互建模方法，其中：
创建了规范的首选交互模型（PIM）
创建了一个从实际用户学习会话中获得的描述性用户交互模型（UIM）
问题解决与决策模型（PDM）用于解释前两个模型之间的差异

1.4.15重用层级（Reuse Levels）

http://www.lybecker.com/blog/2010/06/01/levels-of-reuse-in-software-development/

four levels of reuse（四个重用级别）：
First level of reuse: Copy/paste（第一层重用：复制/粘贴）
Duplicating code or functionality makes it easy to reuse it. It’s a real timesaver at first, but keeping all the duplicates up-to-date and maintaining them is horrifying task. Not to mention the problems when forgetting to update one or more duplicates…
复制代码或功能使其易于重用。起初这是一个真正的节省时间，但是要使所有重复项保持最新状态并进行维护，这是一件令人恐惧的任务。更何况忘记更新一个或多个重复项时的问题…
Second level of reuse: Class libraries（第二层重用：类库）
Reuse at class level or a set of classes in a software library is common and also fairly easy with object-oriented languages.
在类级别或在软件库中的一组类中重用是很常见的，而且使用面向对象的语言也很容易。
Third level of reuse: Design Patterns（第三层重用：设计模式）
Patterns allow you to reuse design ideas and concepts independent of concrete code.
模式使您可以重用独立于具体代码的设计思想和概念。
Fourth level of reuse: Frameworks（第四级重用：框架）
An object-oriented abstract design to solve a specific problem – often very specialized, like Unit Testing frameworks and Object-Relational Mapping frameworks, but can be large, complex or domain specific.
用于解决特定问题的面向对象的抽象设计–通常非常专业，例如单元测试框架和对象关系映射框架，但是可以是大型，复杂或特定于领域的。

1.4.16激活(activation)

https://creately.com/diagram-type/objects/sequence-diagram/activation

Activation elements in the UML Sequence Diagram are boxes on the lifelines. These are also called the method-invocation boxes, and indicate that an object is responding to a message. It starts when the message is received and ends when the object is done handling the message.

UML序列图中的激活元素是生命线上的方框。这些也称为方法调用框，指示对象正在响应消息。它从接收到消息时开始，到对象处理完消息时结束。

1.4.17序列模型（Sequence Models）

https://www.ibm.com/support/knowledgecenter/en/SS3RA7_15.0.0/com.ibm.spss.modeler.h
elp/sequenceset_general.htm

Sequence models are central to NLP: they are models where there is some sort of dependence through time between your inputs. The classical example of a sequence model is the Hidden Markov Model for part-of-speech tagging. Another example is the conditional random field.
序列模型是NLP的核心：它们是在输入之间存在一定时间依存关系的模型。序列模型的经典示例是用于词性标记的隐马尔可夫模型。另一个示例是条件随机字段。
A recurrent neural network is a network that maintains some kind of state. For example, its output could be used as part of the next input, so that information can propogate along as the network passes over the sequence. In the case of an LSTM, for each element in the sequence, there is a corresponding hidden state ht, which in principle can contain information from arbitrary points earlier in the sequence. We can use the hidden state to predict words in a language model, part-of-speech tags, and a myriad of other things.
递归神经网络是维持某种状态的网络。例如，它的输出可以用作下一个输入的一部分，以便信息可以随着网络在序列上传递而传播。对于LSTM，对于序列中的每个元素，都有一个对应的隐藏状态 ht，原则上可以包含序列中任意点的信息。我们可以使用隐藏状态来预测语言模型中的单词，词性标签以及无数其他内容。

1.4.18实际参数(actual parameter)

https://chortle.ccsu.edu/java5/Notes/chap34A/ch34A_3.html

the actual value that is passed into the method by a caller. For example, the 200 used when processDeposit is called is an actual parameter. actual parameters are often called arguments. When a method is called, the formal parameter is temporarily “bound” to the actual parameter.

调用方传递给方法的实际值。例如，调用processDeposit时使用的200是一个实际参数。实际参数通常称为参数。调用方法时，形式参数临时“绑定”到实际参数。

1.4.19异步操作(asynchronous action)

https://www.codeguru.com/csharp/.net/net_asp/mvc/creating-asynchronous-actions-in-asp.net-mvc.htm#:~:text=Asynchronous%20actions%20allow%20you%20to%20handle%20more%20concurrent,how%20to%20create%20them%20in%20an%20ASP.NET%20MVC.

Asynchronous actions allow you to handle more concurrent requests and can be implemented using async / await keywords. Asynchronous actions are useful in situations where you are performing some network operation such as calling a remote service.

异步操作允许理更多的并发请求，并且可以使用async/await关键字来实现。在某些情况下，可以在远程操作中执行远程操作，例如在远程操作中执行服务。

1.4.20二元关联(binary association)

https://www.uml-diagrams.org/association.html

Binary association relates two typed instances. It is normally rendered as a solid line connecting two classifiers, or a solid line connecting a single classifier to itself (the two ends are distinct). The line may consist of one or more connected segments.
A small solid triangle could be placed next to or in place of the name of binary association (drawn as a solid line) to show the order of the ends of the association. The arrow points along the line in the direction of the last end in the order of the association ends. This notation also indicates that the association is to be read from the first end to the last end.

二进制关联关系两个类型化实例。它通常呈现为连接两个分类器的实线，或将单个分类器连接到自身的实线（两端是不同的）。直线可以由一个或多个连接的线段组成。
一个小的实心三角形可以放在二进制关联的名称旁边或代替它（用实线绘制），以显示关联结束的顺序。箭头按关联结束的顺序指向最后一个端点的方向。这种表示法还表示从第一个端点到最后一个端点读取关联。

1.4.21持久对象(persistent object)

https://www.javatpoint.com/q/3243/what-is-the-meaning-of-persistent-object

A persistent object is an object that has been assigned a storage location in a federated database. When you commit the transaction in which you create a persistent object, that object’s data is saved in the database; the object can then be accessed by other processes. A persistent object continues to exist beyond the duration of the process that creates it. In contrast, a transient object exists only within the memory of the process that creates it; when that process terminates, the transient object ceases to exist.

持久对象是在联合数据库中分配了存储位置的对象。当您提交在其中创建持久对象的事务时，该对象的数据将保存在数据库中；然后其他进程可以访问该对象。持久化对象在创建它的进程的持续时间之后继续存在。相反，临时对象只存在于创建它的进程的内存中；当该进程终止时，该临时对象就不再存在。

1.4.22基本类型（Primitive type）

https://www.techopedia.com/definition/24013/primitive-type

Primitive type refers to a whole host of less complex variables and data types in different technologies and programming syntax systems. Some of these are defined by whether the variable needs substructures, or how simple the data type is to represent. Others are defined by whether they are part of a machine language or are otherwise accessible.

基本类型是指在不同的技术和编程语法系统中的一整套不太复杂的变量和数据类型。其中一些是由变量是否需要子结构或数据类型表示的简单程度来定义的。其他的则是由它们是机器语言的一部分还是以其他方式可访问来定义的。

1.4.23系统边界（System boundary）

https://sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/systemboundary.html

A System Boundary element is a non-UML element used to define conceptual boundaries. We can use System Boundaries to help group logically related elements (from a visual perspective, not as part of the UML model).
We can also define a Use Case as the classifier of a System Boundary element, to link the elements enclosed in the System Boundary (such as parts of an Activity diagram) to their representation in a logical Use Case.
The element properties for a System Boundary element comprise the name, the border style, and the number of horizontal or vertical swim lanes. You can also change the overall shape of the System Boundary.
A System Boundary element can be marked as ‘Selectable’, using the element’s context menu. When the element is not selectable, you can click on the other elements within the System Boundary space without activating or selecting the System Boundary itself.

系统边界元素是用于定义概念边界的非UML元素。我们可以使用系统边界来帮助对逻辑相关的元素进行分组（从可视化的角度，而不是作为UML模型的一部分）。
我们还可以将用例定义为系统边界元素的分类器，将封闭在系统边界中的元素（例如活动图的一部分）与其在逻辑用例中的表示联系起来。
系统边界元素的元素属性包括名称、边界样式和水平或垂直泳道的数量。也可以修改系统边界的整体形状。
系统边界元素可以使用元素的上下文菜单标记为“可选”。当图元不可选择时，可以单击系统边界空间内的其他图元，而无需激活或选择系统边界本身。

2.读书笔记

2.1读书笔记一

软件的模拟特性来源于其知识载体的特性：软件在运行中表现岀来的特性、行为应该和应用 的现实情况保持一致。这样，人们通过观察软件的表现就可以得出相应现实问题的答案，即软件“模拟”了现实。
软件的冗余功能问题从另一个侧面反映了它的模拟特性。在软件开发中，一方面只能完成预期功能的60%-70% [Standish 1995],另一方面移交软件中却存在着大量的冗余功能 (接近50% [Young 2002, Standish 2003]),这些功能用户从来不会使用。
软件可以被分为3种类别：面向专业用户的纯工具型软件、面向普通用户的纯工具型软件和 应用型软件。
专业用户通常以软件为中心开展工作，工具软件是他们的主要手段，因此面向专业用户的纯 工具型软件的首要成功标准是要具有功能的复杂性和使用的高效性。功能的复杂可以让专业用 户在执行任务时具有更大的发挥空间和回旋余地。使用的高效可以帮助专业用户更快、更好地 完成任务。应用型软件的模拟特性使得需求处理具有很突岀的特性。相对于软件开发的其他阶段而言，需求处理阶段涉及更多的非技术性和社会性因素，并且其所受的影响也远远高于其他阶段。 20世纪90年代之前的需求处理往往更专注于技术处理，而对其中的非技术性和社会性因素重 视不足。
需求建模与分析是需求处理中的核心活动，它用一些形式化或半形式化的语言进行知识 的描述。一方面，只有通过建模与分析才能将混乱、模糊的用户需求变成清晰、明确的软件需 求，所以它是获取需求处理活动的必然后继，它建立的分析模型是需求处理中最为重要的成 果；另一方面，建模与分析的理论可以帮助人们系统化地看待问题，它可以根据理论或分析中 出现的各种现象指导其他需求处理活动更好地进行。因此，建模与分析活动在需求处理中具有非常重要的地位，以至于人们理所当然地把需求处理工作的重心部署在建模与分析活动中，放在对建模技术的理解和运用上，甚至在传统的软件开发生命周期中用“需求分析”一词 指代整个需求处理阶段。
但在需求处理阶段除了需求建模与分析活动之外，还有其他的活动也应得到重视，理解需求处理中涉及的非技术性和社会性因素与理解建模分析技术一样必要，否则同样会导致软件的失败，这些因素包括组织机构文化、社会背景、商业目标、利益协商等。
传统的需求分析方法，如结构化分析和面向对象分析，都是从设计领域转入分析领域的。虽然它们在设计阶段取得了很大的成功，但它们并不非常适合于需求阶段的技术处理需要，因此它 们在需求处理中的应用具有一定的先天缺陷。
需求处理是软件工程的起始阶段，设计、实现等后续阶段的正确性都以它的正确性为前提。如果在需求处理过程中有错误未能解决，则其后的所有阶段都会受到影响，因此与需求有关的错误修复代价较高，需求问题对软件成败的影响较大。统计表明，在需求阶段发生的错误如果到了维护阶段才发现，则在维护阶段进行修复的代价可能高达需求阶段修复代价的100~200倍 [Boehm 1981, Boehm 2001 ]，这种递增效应也说明了需求问题的高代价性。需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需 求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应。
从细节来看，可以定义如下：需求工程是软件工程的一个分支，它关注软件系统所应实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束，同时也关注以上因素和准确的软件行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。
需求工程活动包括需求开发和需求管理两个方面。需求开发是因为需求工程的“需求”特 性而存在的，它们是专门用来处理需求的软件技术，包括需求获取、需求分析、需求规格说明和需 求验证4个具体的活动。需求管理是因为需求工程的“工程”特性而存在的，它的目的是在开发活动之后，保证所确定的需求能够在后续的项目活动中有效地发挥作用，保证各种活动的开展都符合需求要求。在软件开发的各项活动中，需求工程的任务是连接现实世界与计算机世界，将现实世界的知识内容转化为计算机世界的工作基础，让软件设计、实现、测试等后续的软件开发活动将精力集 中在计算机世界中来。需求工程师是负责完成需求工程主要任务的专门人员，所以他负责衔接现实世界和计算机世界，简单说就是涉众与开发者之间的桥梁。需求工程师的重要性就体现在他的桥梁作用上。
问题在现实世界与软件系统的互动中得到解决。题域的背景信息又被称为问题域特性(problem domain feature) o与需求相区别的是，问题域是自治的，它有自己的运行规律，而且这些规律不会因解系统的引入而发生改变。需求是一种 对未来的期望，是可以打折、部分满足甚至不予满足的；而问题域特性是既定现实，可以改善但不 能忽视，更不能违背的。例如对于需求“将利润率提高到5%”，可以部分满足，只提升到3%。但 是如果用户的销售市场遍布全国(问题域特性)，就不能仅考虑一个地点的销售工作状况。
软件系统通过影响问题域帮助人们解决问题，所以［Jackson 1995b］称之为解系统(solution system)。在解系统中软件起着主要的作用，它是软件解决方案在通用计算机上的实现。

2.2读书笔记二

处于问题域之外的解系统之所以能解决问题域中的问题，是因为问题域与解系统之间存在有效的互动，并在互动中互相影响。而问题域与解系统能够形成互动的基础是解系统部分模拟了问题域,[Jackson 1995b]将这种模拟性称为共享现象(share phenomenon) 。
模拟是指其中一方仿制另一方的信息。解系统对问题域的模拟则更加复杂一些, 它们之间的模拟性带有交互性：一方面，解系统会在自身中保持一份与问题域现象一致的信息, 并随着问题域现象的变化而变化；另一方面，问题域会期待在解系统中看到一致的信息，并据此展开自己的行为。
因为解系统解决问题的方法是改变共享知识，影响问题域的运行，进而满足用户的需求。所以需求规格说明主要包括两部分（如图2-5所示）：对共享现象（模型）的描述和对系统对共享现象所施加的操作的描述。这也是软件系统中最为核心的两个部分:数据与功能。
如果拥有描述明确的问题域特性E和定义良好 的系统行为S,就可以很容易地发现将系统应用到问题域后会产生的效果。这种效果如果符合预期的需求X,那么系统就是满足人们需要的系统。所以需求工程的目的就是根据E,构建S,使得E和S的联合作用效果符合需求R：E,SJR。
需求是问题解决的期望，问题是可大可小的，期望自然也是可大可小的。例如，一个超市收银员的问题可以是“工作效率太低（大）”，也可以是“商品销售过程太繁琐（中）”， 还 可以是“销 售时计算总价不方便（小）”。
问题和期望粒度不同的现象被称为需求的不同抽象层次。
业务需求是抽象层次最高的需求，是系统建立的战略岀发点，表现为高层次的目标（objec- tive）,它描述了组织为什么要开发系统。例如超市管理系统可以有如下业务需求BR1~BR4O业务需求通常来自项目的投资人、购买产品的顾客、实际用户的管理者、市场营销部门或产品策划部门。
BR1：在系统使用6个月后，商品积压、缺货和报废的现象减少50%。
BR2：在系统使用3个月后，销售人员工作效率提高50%。
BR3：在系统使用6个月后，店铺运营成本降低15%0
•范围：人力成本和库存成本。
・度量：检查平均每个店铺的员工数量和平均每10000元销售额的库存成本。
BR4：在系统使用6个月后，销售额度提高20%（最好情况：40%；最可能情况：20%；最坏情况：10%。）
业务需求必须是可验证的，其验证标准可以是一个数值指标，如BR1-BR4；也可以是一个直 接的有无、是否等判定，例如，下述BR5、BR6验收时就是有与没有的判定。
BR5：跟踪记录储户的存取款情况。
BR6：跟踪记录VIP顾客信息。
业务需求可验证的数值指标是通过研究问题域的背景资料得出的，例如，若大多数商品从入 库到出库的销售周期是6个月，那么就可以将BR1的第一个条件设定为“系统使用6个月后”；如果详细列举原来导致商品积压、缺货和报废的原因及比率，将软件系统能解决的原因及比率累 加后达到50%,就可以将BR1的后一个验证条件写为“商品积压、缺货和报废的现象减少50%”。再如，如果收银员从新手到熟练使用系统的培训周期为3个月，就可以将BR2的第一个条件写 为“系统使用3个月后”；如果实例研究中收银员使用与不使用系统的工作时间为1 ：2,就可以将BR2的第二个条件写为“销售人员工作效率提高50%”。
为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性(feature)o高层次的解决方案及系统特性指出了系统建立的方向，参与各方必须就它们 达成一致，以建立一个共同的前景(vision)，保证涉众朝着同一个方向努力。以支持业务需求的 满足为衡量标准，系统特性说明了系统为用户提供的各项功能，它限定了系统的范围(scope),定 义良好的系统特性可以帮助用户和开发者确定系统的边界。
为满足超市管理系统的业务需求BR1-BR4,可以设计特性为SF1 -SF10的高层次解决方案。其中 SF1、SF3、SF7 针对 BR1 与 BR3 ,SF2 针对 BR1 与 BR4, SF4、SF5、SF8、SF9 针对 BR4, SF10 针对 BR2 与 BR3。
SF1：分析店铺商品库存，发现可能的商品积压、缺货和报废现象。
SF2：根据市场变化调整销售的商品。
SF3：制定促销手段，处理积压商品。
SF4：与生产厂家联合进行商品促销。
SF5：制定促销手段进行销售竞争。
SF6：掌握员工变动和授权情况。
SF7：处理商品入库与出库。
SF8：发展会员，提高顾客回头率。
SF9：允许积分兑换商品和赠送吸引会员的礼品，提高会员满意度。
SF10：帮助收银员处理销售与退货任务。
高层次的目标是由组织的决策者提出的，但普通用户才是组织中任务的实际执行者，只有通过一套具体并且合理的业务流程才能真正实现目标。用户需求就是执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。用户需求主要来自系统的使用者——用户。在有些情况下，系统的直接用户不可知，如通用的软件系统或社会服务领域的软件系统等，所以用户需求也可能来自间接的渠道，如销售人员和售后支持人员等。
用户需求是对任务的期望，所以其基本表达方式为“xx用户可以使用系统完成xx任务”。用户任务应该是有目标性、有价值的活动。例如在银行ATM系统中，取款、存款、转账都是合理的用户需求，因为它们各自代表了用户的一个目标，但“向ATM中插入银行卡”就不是一个合理的 用户需求，因为用户不会无目的地“向ATM中插入银行卡”。再如，UR1是一个合理的用户需 求，因为它表达了收银员的一个任务，但是“收银员使用扫描仪扫描商品条码”就不是合理的用 户需求，因为收银员的目的是记录商品，而扫描条码只是手段。
业务需求描述了系统的目标与效益，适合决策者；用户需求描述了具体任务，适合用户；它 们都不适合于软件开发者。适合软件开发者的需求层次是系统级需求，它关注的是软件系统 的行为，尤其是系统与外界的交互行为：在接收到一个外界请求时，软件系统应该给外界提供 响应。所以系统级需求的典型形式是“系统可以XXX”或者"在XX用户提出XX请求时，系统应 该XXX”。

2.3读书笔记三

需求获取是从人、文档或环境中获取需求的过程。获取过程并不是简单地将定义良好的需求从人、文档或环境中直接转移到获取的结果文档上，需求工程师必须要利用各种方法和技术来“发现”需求。
需求开发的过程包含有学习和认知的过程，而学习和认知的过程是递进的，即学习一点，增 加一些认知，然后在新的认知的基础上继续学习。因此需求获取和需求分析是交织在一起的，需求工程师需要获取一些信息，随即进行分析和整理，理解、认知到一定程度后再确定要进一步获 取的内容。
获取的目的是发现用户的问题，并经过需求分析步骤转化为用户的需求。要想和用户就业务问题进行交流，需求工程师应先具备能够和用户进行交流的知识基础，否则两者之间无法形成 有效的沟通。因此需求工程师需要先收集系统的背景资料以形成一个基础的知识框架，如企业 的业务状况等。如果需要对背景资料进行非常深入的了解（如进行产品线开发），就需要应用相 关的需求分析方法（如领域分析等）对收集的资料进行整合与处理，当然这是需求分析的任务。
在进行信息获取时，不同用户往往会从自身的立场出发考虑问题，提出相应的功能要求。这样，当软件系统涉及很多用户时常会发现用户相互之间对系统的期望有着很大的差距。因此，需要根据业务需求明确高层次的解决方案，确定软件产品未来的形式，定义项目的前景。有了共同的项目前景，不同的用户就可以从共同的方向上理解问题，提出对系统的功能要求。而且当用户之间发生需求冲突时，还可以利用项目前景指导需求冲突的协商解决。

3.项目前景

随着时代的发展，各种编程语言已经较为完善，计算机科学技术已经趋于成熟且已运用到各行各业，为不少企业提供了便利，减少了运营成本，增加了盈利，提高了企业办事效率。但从目前来看，许多电影院目前仍在采用传统的电影票售卖方法，这对影院的人力物力资源消耗都较大，且增加了影院的运营成本以及花费了客户大量的时间。此系统能够快速有效的解决这些问题，提高影院的工作效率，降低影院经营成本，减少顾客买电影票所花费的部分不必要的时间。

4.对影院管理系统的发展建议

影院管理系统的发展前景较好。在此我有一些对影院管理系统的发展建议。
作为主要为普通人员服务的系统，首先此系统的页面应简洁易懂，方便人们操作。
从系统功能来讲，开发人员应做好需求的调查与分析，做出完善的系统。

A002-185-2502-李林相关推荐

1. 阿里2018营收2502亿元，云计算业务增幅超100%

   整理 | 阿司匹林 出品 | AI科技大本营(公众号ID:rgznai100) 5 月 4 日,阿里巴巴集团公布了 2018 财年第四季度(2018 年 1 月 1 日-3 月 31 日)的财报及 2 ...

2. L - Subway POJ - 2502

   L - Subway POJ - 2502 题意: 从 家出发步行与坐 subway 交替进行,问最小的时间花费,最终四舍五入答案为 整数 存图难 四舍五入: double b int a = b + ...

3. 软件安装——internal error2503/2502

   2019独角兽企业重金招聘Python工程师标准>>> 安装新的软件后先报internal error 2503,随后报internal error 2502.就是不让我装新的软件, ...

4. BZOJ 2502: 清理雪道 [最小流]

   2502: 清理雪道 题意:任意点出发任意次每条边至少经过一次最小花费. 下界1,裸最小流.... #include <iostream> #include <cstdio> ...

5. Win10 安装程序错误2502/2503 拒绝访问 解决

   Win10系统安装程序错误2502/2503解决 使用某些Windows Installer安装程序时,有时候会出现安装和卸载失败的问题,错误代码为2502或2503.这一问题出现在Win7/Win8 ...

6. 已解决：Connecting to raw.githubusercontent.com |185.199.109.133|:443... Unable to establish SSL connect

   1.问题描述 搭建k8s集群时,有一步需要部署flannel网络,首先需要下载一个yml文件,下载方式如下: wget https://raw.githubusercontent.com/coreos ...

7. Codeforses 185 A Plant 思维 规律

   题目链接: http://codeforces.com/problemset/problem/185/A 题目描述: 给你一个三角形,每次在上三角形中画一个下三角形, 在下三角形中画一个上三角形, 求 ...

8. 4.2 算法之数论 185 反正切函数的应用 scratch

   http://noi.openjudge.cn/ch0402/185/ /* 4.2 算法之数论 185 反正切函数的应用 http://noi.openjudge.cn/ch0402/185/ */ ...

9. 4.2 算法之数论 185 反正切函数的应用 python

   http://noi.openjudge.cn/ch0402/185/ """4.2 算法之数论 185 反正切函数的应用 http://noi.openjudge.cn ...

10. 5 分钟商学院精细笔记 000~185

    从今天开始,我会在博客里转载优秀的非技术类课程的笔记. [5 分钟商学院]是刘润在得到上发布的课程,一共 260 课. 笔记由[洋_葱头]整理,涵盖了前 185 课. 下载: CSDN Github

最新文章

1. VS2017报错---无可用源
2. 深度学习——自动编码器，对称网络结构
3. js - prototype 继承
4. 5.6 Column Attribute
5. HDU 4912 Paths on the tree（LCA+贪心）
6. Docker的运行机制
7. 【边缘检测】RCF: Richer Convolutional Features for Edge Detection
8. 护理方面关于人工智能的构想_如何提出惊人的AI，ML或数据科学项目构想。
9. centos7 源码安装goaccess
10. java分页代码思路,记录--java 分页 思路 (hibernate关键代码)
11. python省市区三级联动_Ajax实现省市区三级级联详解
12. WAS生成的文件：javacore.***.txt 、heapdump.***.phd、core.***.dmp、Snap.***.trc
13. linux 之静默安装oracle
14. 数值分析方阵的QR分解
15. ubuntu中文乱码--添加中文字符集
16. Docker 安装和基础用法
17. #879273#基于django/neo4j的通讯录与QQ好友关系管理系统
18. Java中处理tiff文件
19. 迅雷开放离线下载试用，每天8000名额，速度来抢！
20. 致信oa系统服务器ip,OA系统登陆考勤IP控制

热门文章

1. Python之循序渐进
2. 博客作业回答记录1--“软件工程是不是教会不怎么会写程序的人开发软件？你的观点？”
3. 美发屋App-业余爱好
4. GMII（Gigabit MII）
5. 36岁的联想，像极了109岁的IBM？
6. MySQL导出csv文件，数字过长出现科学计数法的问题
7. 简单的了解下 Service Worker
8. ubuntu18.04 - igb_uio: Unknown symbol
9. 加强云上探索与实践，筑牢数字经济发展之根
10. hofstede六个维度指数指标_这个指数这么火！到底应该买哪只场外基金参与？