计算机科学与工程学院实验报告
|
课程名称 |
软件需求分析与建模 |
班级 |
18软工5班 |
|
||||
|
实验名称 |
软件需求分析与建模读书心得与小组项目的发展建议 |
教导教师 |
董瑞生 |
|
||||
|
姓名 |
陈浩雄 |
学号 |
1814080902534 |
日期 |
2020年12月20日 |
|
||
|
|
|
|
|
|
||||
摘要
随着软件系统规模的扩大和复杂程度的增长，以需求分析为重心的传统需求处理技术已经不能适应现在软件技术发展的要求，完整的需求工程过程应运而生。
于是软件的需求分析和建模变得愈加重要，这学期通过对《软件需求分析与建模》以及部分参考文献的阅读，我对软件需求工程有了进一步的认识，理解了软件需求工程的定位，关注点，基本术语，过程框架等知识。
需求分析与建模是方便我们对不同类型的需求有比较准确的认识，特别是在基本术语这方便，包括对问题、问题域、需求、规格说明、解决方案、业务需求等等。
该书介绍了软件需求工程产生的背景、需求工程和软件需求工程师的定位和主要关注内容。这些内容能够帮助我们认识到软件需求工程的复杂性和需求工程中非技术因素的重要性。
我们可以在需求分析与建模应有的内容建议中，建立我们对软件需求工程过程的整体理解并深入理解需求工程过程的关键特征，也可以了解到需求工程所需关注需求以及具备的优秀特性。
关键词：需求分析 建模 项目 建议
目录
1 CH1 1
1.1 Requirements baseline(需求基线) 1
1.2 deployment diagram(部署图) 2
1.3 derived element(导出元素) 5
1.4 development process(开发流程) 6
1.5 distribution unit(分配装置) 8
1.6 generalizable element(网络可泛化元素) 9
1.7 interaction diagram(交互图) 11
1.8 internal transition(内部转移) 15
1.9 model elaboration(模型精化) 17
1.10 multiple inheritance(多重继承) 19
2 CH2 21
2.1 binary association（二元关联关系）. 21
2.2 active object（活动对象）. 21
2.3 activity graph （活动图）. 22
2.4 actual parameter （实际参数）. 25
2.5 aggregation （聚合）. 25
2.6 cardinality （基数）. 27
2.7 association class（关联类）. 28
2.8 association end （关联端）. 30
2.9 asynchronous action （异步动作）. 31
2.10 behavioral feature （行为特征）. 32
3 CH3 34
3.1 Entity-relationship model（实体关系模型）. 34
3.2 Sequence diagram（时序图）. 34
3.3 Structured Analysis（结构分析）. 36
3.4 Dataflow diagram（数据流图）. 41
3.5 Context diagram（范围图）. 43
3.6 Use case diagram（用例图）. 45
3.7 System boundary（系统边界）. 48
3.8 Acceptance test（验收测试）. 49
3.9 containment hierarchy（包含层次结构）. 55
3.10 Activity diagram（活动图）. 56
4 CH4 60
4.1 collaboration diagram（合作图）. 60
4.2 Steering committee(指导委员会) 62
4.3 Inspection(检查) 64
4.4 postcondition（后置条件）. 66
4.5 Block Definition Diagram(块定义图) 67
4.6 Requirement Diagram（需求图) 69
4.7 fault tolerance（容错）. 72
4.8 action sequence(操作序列) 74
4.9 Non-functional requirement(非功能性需求 ) 77
4.10 Performance requirement(性能要求) 79
5 读书心得. 82
6 小组项目发展建议. 82
1 CH1
1.1 Requirements baseline(需求基线)
【定义】
A baseline for a set of requirements.
一组需求基线
【链接】
|
https://www.jamasoftware.com/blog/defining-requirement-baseline/ |
|
https://www.sciencedirect.com/topics/computer-science/requirement-baseline/ |
【原文】
What is a Requirements 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.
Implementing a Requirements Baseline
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.
When to Perform a Requirements Baseline
Business analysts sometimes struggle with exactly when to define a requirements baseline. It’s an important decision because establishing the baseline has the following implications:\Formal change control begins. Change requests are made against an established baseline. The baseline. therefore, provides the point of reference for each proposed change. Make sure your change control process and players are in place before you define any project baselines.
- Project managers determine the staffing levels and budgets needed.
- Project managers make schedule commitments.
【翻译】
什么是需求基准？
需求基准是 及时的快照，代表已承诺，已审核和已批准的特定产品版本的一组需求。
实施需求基准
范围定义将内容区分是什么，而需求基线则仅明确标识项目将要实施的那些需求规范。基线不是有形项目，而是已定义的项目列表。一个可能的存储位置是软件需求规范（SRS）文档。
何时执行需求基准
正式变更控制开始。更改请求是根据已建立的基准进行的。基线。因此，为每个提议的更改提供了参考。在定义任何项目基准之前，请确保您的变更控制流程和参与者已经就位。
- 项目经理确定所需的人员配备水平和预算。
- 项目经理做出进度承诺。
1.2 deployment diagram(部署图)
【定义】
A diagram that shows the configuration of run-time processing nodes and the components, processes, and objects that live on them. Components represent run-time manifestations of code units.
显示运行时处理节点的配置以及这些节点的组件、进程和对象的图表。组件表示代码单元的运行时表现。
【链接】
|
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-deployment-diagram/ |
【原文】
What is Deployment Diagram?
A UML deployment diagram is a diagram that shows the configuration of run time processing nodes and the components that live on them. Deployment diagrams is a kind of structure diagram used in modeling the physical aspects of an object-oriented system. They are often be used to model the static deployment view of a system (topology of the hardware).
When to Use Deployment Diagram
l What existing systems will the newly added system need to interact or integrate with?
l How robust does system need to be (e.g., redundant hardware in case of a system failure)?
l What and who will connect to or interact with system, and how will they do it
l What middleware, including the operating system and communications approaches and protocols, will system use?
l What hardware and software will users directly interact with (PCs, network computers, browsers, etc.)?
l How will you monitor the system once deployed?
l How secure does the system needs to be (needs a firewall, physically secure hardware, etc.)?
Purpose of Deployment Diagrams
l They show the structure of the run-time system
l They capture the hardware that will be used to implement the system and the links between different items of hardware.
l They model physical hardware elements and the communication paths between them
l They can be used to plan the architecture of a system.
l They are also useful for Document the deployment of software components or nodes
Deployment Diagram at a Glance
Deployment diagrams are important for visualizing, specifying, and documenting embedded, client/server, and distributed systems and also for managing executable systems through forward and reverse engineering.
A deployment diagram is just a special kind of class diagram, which focuses on a system's nodes. Graphically, a deployment diagram is a collection of vertices and arcs.
【翻译】
什么是部署图？
UML部署图是显示运行时处理节点及其上存在的组件的配置的图。 部署图是一种用于对面向对象系统的物理方面进行建模的结构图。 它们通常用于建模系统的静态部署视图（硬件拓扑）。
何时使用部署图
l 新添加的系统需要与哪些现有系统进行交互或集成？
l 系统需要有多强健（例如，系统出现故障时的冗余硬件）？
l 什么和谁将连接到系统或与系统交互，以及他们将如何做
l 系统将使用哪种中间件，包括操作系统，通信方法和协议？
l 用户将直接与哪些硬件和软件进行交互（PC，网络计算机，浏览器等）？
l 部署后如何监控系统？
l 系统需要有多安全（需要防火墙，物理上安全的硬件等）？
部署图的目的
l 它们显示了运行时系统的结构
l 它们捕获将用于实施系统的硬件以及不同硬件项之间的链接。
l 他们对物理硬件元素及其之间的通信路径进行建模
l 它们可用于计划系统的体系结构。
l 它们对于记录软件组件或节点的部署也很有用
部署图一览
部署图对于可视化，指定和记录嵌入式，客户端/服务器和分布式系统以及通过正向和反向工程管理可执行系统非常重要。
部署图只是一种特殊的类图，它专注于系统的节点。在图形上，部署图是顶点和弧的集合。
1.3 derived element(导出元素)
【定义】
A model element that can be computed from another element, but that is shown for clarity or that is included for design purposes even though it adds no semantic information.
【链接】
|
https://doc-archives.microstrategy.com/producthelp/10.8/InMemoryAnalytics/WebHelp/Lang_1033/Content/InMemoryAnalysis/Derived_elements.htm |
|
http://ancillaryinsights.com/ai/help/WebUser/WebHelp/Lang_1033/Derived_elements.htm |
|
https://www.oreilly.com/library/view/applying-uml-and/0130925691/0130925691_ch27lev1sec7.html |
【原文】
Derived Elements
A derived element can be determined from others. Attributes and associations are the most common derived elements. When should derived elements be shown?
Avoid showing derived elements in a diagram, since they add complexity without new information. However, add a derived element when it is prominent in the terminology, and excluding it impairs comprehension.
【翻译】
可以从其他元素确定派生元素。属性和关联是最常见的派生元素。什么时候应该显示派生元素？
避免在图中显示派生元素，因为它们会增加没有新信息的复杂性。但是，在派生的术语中突出显示时添加派生元素，将其排除会损害理解能力。
1.4 development process(开发流程)
【定义】
A set of partially ordered steps performed for a given purpose during software development, such as constructing models or implementing models
【链接】
|
https://en.wikipedia.org/wiki/Software_development_process#:~:text=In%20software%20engineering%2C%20a%20software%20development%20process%20is,known%20as%20a%20software%20development%20life%20cycle%20%28SDLC%29. |
|
https://www.fool.com/the-blueprint/product-development-process/ |
|
https://www.synapseindia.com/6-stages-of-software-development-process/141 |
【原文】
In software engineering, a software development process is the process of dividing software development work into distinct phases to improve design, product management, and project management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.
Most modern development processes can be vaguely described as agile. Other methodologies include waterfall, prototyping, iterative and incremental development, spiral development, rapid application development, and extreme programming.
【翻译】
在软件工程中，软件开发过程是将软件开发工作划分为不同阶段以改善设计，产品管理和项目管理的过程。它也被称为软件开发生命周期（SDLC）。该方法可以包括由项目团队创建和完成以开发或维护应用程序的特定可交付成果和工件的预定义。
可以将大多数现代开发过程模糊地描述为敏捷。其他方法包括瀑布式，原型开发，迭代式和增量式开发，螺旋式开发，快速的应用程序开发以及极限编程。
1.5 distribution unit(分配装置)
【定义】
A set of objects or components that are allocated to a process or a processor as a group. A distribution unit can be represented by a run-time composite or an aggregate.
【链接】
|
https://en.wikipedia.org/wiki/Power_distribution_unit |
|
https://searchdatacenter.techtarget.com/definition/power-distribution-unit-PDU |
|
https://www.techopedia.com/definition/1751/power-distribution-unit-pdu |
【原文】
A power distribution unit (PDU) is a type of electrical component that distributes and manages electricity supply to computers, servers and networking devices within a data center environment.
It provides a central unit to control and distribute electricity across the data center components.
Power distribution units are also known as main distribution units (MDU).
【翻译】
配电单元（PDU）是一种电气组件，用于分配和管理数据中心环境中计算机，服务器和网络设备的电力供应。它提供了一个*单元，用于控制和分配数据中心各个组件之间的电力。
1.6 generalizable element(网络可泛化元素)
【定义】
A model element that may participate in a generalization relationship.
【链接】
|
https://www.oreilly.com/library/view/unified-modeling-language/0321245628/0321245628_ch14lev1sec249.html |
|
https://www.uml-diagrams.org/generalization.html |
【原文】
A generalization is a binary taxonomic (i.e. related to classification) directed relationship between a more general classifier (superclass) and a more specific classifier (subclass).
Each instance of the specific classifier is also an indirect instance of the general classifier, so that we can say "Patient is a Person", "Savings account is an Account", etc. Because of this, generalization relationship is also informally called "Is A" relationship.
Generalization is owned by the specific classifier.
A generalization is shown as a line with a hollow triangle as an arrowhead between the symbols representing the involved classifiers. The arrowhead points to the symbol representing the general classifier. This notation is referred to as the "separate target style."
Generalization relationships that reference the same general classifier can also be connected together in the "shared target style."
【翻译】
泛化是更一般的分类器（超类）和更特定的分类器（子类）之间的二进制分类法（即与分类有关）。
特定分类器的每个实例也是通用分类器的间接实例，因此我们可以说“患者是一个人”，“储蓄账户是一个账户”等。因此，泛化关系也被非正式地称为“是 A”关系。
泛化归特定分类器所有。
泛化表示为带有空心三角形的线，该空心三角形作为代表所涉及分类器的符号之间的箭头。 箭头指向代表通用分类器的符号。 该表示法称为“单独的目标样式”。
引用同一通用分类器的通用关系也可以“共享目标样式”连接在一起。
1.7 interaction diagram(交互图)
【定义】
A generic term that applies to several types of diagrams that emphasize object interactions. These include: collaboration diagrams, sequence diagrams, and activity diagrams.
【链接】
|
https://www.ccs.neu.edu/home/futrelle/teaching/com1204sp2001/uml/interaction/interactions.htm |
|
https://www.tutorialspoint.com/uml/uml_interaction_diagram.htm |
|
https://www.guru99.com/interaction-collaboration-sequence-diagrams-examples.html |
【原文】
Interaction Diagrams
Interaction diagrams are models that describe how a group of objects collaborate in some behavior - typically a single use-case. The diagrams show a number of example objects and the messages that are passed between these objects within the use-case.
I'll illustrate the approach with the following simple use-case. In this behavior the order entry window sends a prepare message to an order. The order then sends prepare to each order line on the order. The order line first checks the stock item, and if the check returns true it removes stock from the stock item. If stock item falls below the reorder level it requests a new delivery.
Interaction diagrams come in two forms, both present in the UML. The first form is the sequence diagram. In this form objects are shown as vertical lines with the messages as horizontal lines between them. This form was first popularized by Jacobson. The diagram below shows this form in its UML notation. The sequence of messages is indicated by reading down the page.
The second form of the interaction diagram is the collaboration diagram. Here the example objects are shown as icons. Again arrows indicate the messages sent in the use case. This time the sequence is indicated by a numbering scheme. Simple collaboration diagrams simply number the messages in sequence. More complex schemes use a decimal numbering approach to indicate if messages are sent as part of the implementation of another message. In addition a letter can be used to show concurrent threads.
When to Use Them
Interaction diagrams should be used when you want to look at the behavior of several objects within a single use case. They are good at showing the collaborations between the objects, they are not so good at precise definition of the behavior.
【翻译】
交互图是描述一组对象如何以某种行为（通常是单个用例）进行协作的模型。这些图显示了许多示例对象以及用例中在这些对象之间传递的消息。
我将通过以下简单的用例来说明这种方法。在这种情况下，预约输入窗口会向预约发送一条准备消息。然后，预约将准备发送到预约上的每个预约单。预约单首先检查项目，如果检查返回true，它将从库存项目中删除库存。如果库存项目低于预约人数，它将请求拒绝。
交互图有两种形式，都存在于UML中。第一种形式是顺序图。在这种形式中，对象显示为垂直线，消息之间为水平线。这种形式最早由Jacobson推广。下图以UML表示法显示了此形式。通过阅读页面可以指示消息的顺序。
交互图的第二种形式是协作图。此处示例对象显示为图标。箭头再次指示用例中发送的消息。这次，该序列由编号方案表示。简单的协作图仅按顺序编号消息。更复杂的方案使用十进制编号方法来指示是否将消息作为另一条消息的实现的一部分发送。另外，可以使用字母来显示并发线程。
交互图的一大优势就是它的简单性。由于交互图非常简单，因此很难写很多。但是，它们确实有弱点，主要的原因是，尽管他们擅长描述行为：但没有定义行为。它们通常不显示给出完整的计算描述所需的所有迭代和控制。为了尝试在UML中进行补救，已经做了很多事情。
何时使用它们
当您要查看单个用例中多个对象的行为时，应使用交互图。它们擅长显示对象之间的协作，而不能精确定义行为。
1.8 internal transition(内部转移)
【定义】
A transition signifying a response to an event without changing the state of an object.
【链接】
|
https://statecharts.github.io/glossary/local-transition.html |
|
https://sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/internal_transition.html |
|
https://docs.nomagic.com/display/MD190/Internal+Transition |
【原文】
If you need to define an internal Transition in a State, you can do so by creating an external self-Transition connector (where the Source and Target are the same State) and then changing the connector kind property. The self-Transition connector is then removed from the diagram and the internal Transition displays in a compartment inside the State element.
Notes
l To view or edit the properties of the internal Transition, double-click on the entry in the compartment within the State
l If you need multiple internal transitions, including those with the same Trigger but different guards, you create them separately with each Transition having its own guard
【翻译】
如果需要在一个状态中定义一个内部过渡，则可以通过创建一个外部自我过渡连接器（其中“源”和“目标”是相同的状态）然后更改连接器的种类属性来实现。然后，将自转换连接器从图中移除，内部转换显示在State元素内部的隔离专区中。
小结
要查看或编辑内部Transition的属性，请双击State内隔离专区中的条目
如果您需要多个内部过渡，包括具有相同触发器但保护装置不同的内部过渡，则可以分别创建每个过渡都具有自己的保护装置的过渡
1.9 model elaboration(模型精化)
【定义】
The process of generating a repository type from a published model. Includes the generation of interfaces and implementations which allows repositories to be instantiated and populated based on, and in compliance with, the model elaborated.
【链接】
|
https://en.wikipedia.org/wiki/Elaboration_likelihood_model |
|
https://www.toolshero.com/communication-skills/elaboration-likelihood-model-elm/ |
|
http://www.cios.org/encyclopedia/persuasion/Helaboration_2routes.htm |
【原文】
What is the Elaboration Likelihood Model?
The Elaboration Likelihood Model (ELM) of persuasion is a dual process theory that describes the change of attitudes and behaviour. The theory explains how attitudes are formed and reinforced by persuasive arguments. The idea is that when a person is presented with information, this person will process this information on a certain level of elaboration. In this context, this means the effort a person takes to evaluate, remember and accept or reject the message. According to the model, this is possible in two ways. The level of effort can be low or high. The level of elaboration subsequently determines the processing route the message takes: central or peripheral.
Elaboration Likelihood Model and Persuasion
Persuasion often has a negative reputation. It’s connected to swindling or to being confronted with things people aren’t asking for. However, persuasion isn’t inherently negative. In fact, persuasion is everywhere, and it’s a process of influence. This influence can be used positively or negatively. In his theory ‘The Dynamics of Persuasion’, Richard Perloff explains exactly what the power of persuasion is.
【翻译】
细化可能性模型是什么？
说服力的细化可能性模型（ELM）是一个双重过程理论，描述了态度和行为的变化。该理论解释了有说服力的论点是如何形成和强化态度的。这样的想法是，当向一个人提供信息时，该人将在一定的阐述水平上处理该信息。在这种情况下，这意味着人们要努力评估，记住和接受或拒绝该消息。根据模型，这可以通过两种方式实现。努力程度可以低或高。详细程度随后确定了消息采用的处理路径：*还是外围。
细化可能性模型和说服力
说服力通常具有负面声誉。它与欺诈或面临人们不要求的事物有关。但是，说服并不是天生的负面。实际上，说服力无处不在，这是一个影响力的过程。可以正面或负面地使用这种影响。理查德·佩罗夫（Richard Perloff）在其理论“说服力的动态”中，确切地解释了说服力的含义。
1.10 multiple inheritance(多重继承)
【定义】
A semantic variation of generalization in which a type may have more than one supertype. Contrast: single inheritance.
【链接】
|
https://www.geeksforgeeks.org/java-and-multiple-inheritance/ |
|
https://docs.oracle.com/javase/tutorial/java/IandI/multipleinheritance.html |
|
https://www.python-course.eu/python3_multiple_inheritance.php |
【原文】
Multiple Inheritance of State, Implementation, and Type
Multiple inheritance of implementation is the ability to inherit method definitions from multiple classes. Problems arise with this type of multiple inheritance, such as name conflicts and ambiguity. When compilers of programming languages that support this type of multiple inheritance encounter superclasses that contain methods with the same name, they sometimes cannot determine which member or method to access or invoke. In addition, a programmer can unwittingly introduce a name conflict by adding a new method to a superclass. Default methods introduce one form of multiple inheritance of implementation. A class can implement more than one interface, which can contain default methods that have the same name. The Java compiler provides some rules to determine which default method a particular class uses.
【翻译】
状态，实现和类型的多重继承
实现的多重继承是从多个类继承方法定义的能力。这种类型的多重继承会产生问题，例如名称冲突和歧义。当支持这种多重继承的编程语言的编译器遇到包含具有相同名称的方法的超类时，它们有时无法确定要访问或调用的成员或方法。另外，程序员可以通过向超类添加新方法来无意间引入名称冲突。 默认方法介绍实现的多重继承的一种形式。一个类可以实现多个接口，该接口可以包含具有相同名称的默认方法。Java编译器提供了一些规则来确定特定类使用哪种默认方法。
2 CH2
2.1 binary association（二元关联关系）
【定义】
An association between two classes. A special case of an nary association.
【链接】
|
https://www.sciencedirect.com/topics/computer-science/binary-association |
|
https://binaryterms.com/link-and-association.html |
|
https://en.wikipedia.org/wiki/Class_diagram |
【原文】
An association between two classes. A special case of an nary association.
【翻译】
两个类之间的关联。 一元关系的特殊情况
2.2 active object（活动对象）
【定义】
An object that owns a thread and can initiate control activity. An instance of active class.
【链接】
|
https://www.techwalla.com/articles/the-difference-between-a-passive-object-an-active-object-in-uml |
|
https://www.codeproject.com/articles/56617/applied-long-running-active-object-pattern |
【原文】
Active Objects
In UML, active classes, and therefore active objects, exist in their own thread of operations and have their own address space. If execution, or code activity, is thought of in terms of flow, active objects can start or control that flow. Active objects, in other words, are sequential and do something: modify variables, change program behavior, and so on. In UML, active classes and objects are distinguished by having a thicker border than passive objects.
【翻译】
活动对象
在UML中，活动类（以及活动对象）存在于它们自己的操作线程中，并具有自己的地址空间。 如果从流的角度考虑执行或代码活动，则活动对象可以启动或控制该流。 换句话说，活动对象是顺序的并且可以执行某些操作：修改变量，更改程序行为等。 在UML中，主动类和对象的区别在于边框比被动对象厚。
2.3 activity graph （活动图）
【定义】
A special case of a state machine that is used to model processes involving one or more classifiers.
【链接】
|
https://en.wikipedia.org/wiki/Activity_diagram |
|
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-activity-diagram/ |
|
https://www.tutorialspoint.com/uml/uml_activity_diagram.htm |
【原文】
Activity diagram is another important behavioral diagram in UML diagram to describe dynamic aspects of the system. Activity diagram is essentially an advanced version of flow chart that modeling the flow from one activity to another activity.
When to Use Activity Diagram
Activity Diagrams describe how activities are coordinated to provide a service which can be at different levels of abstraction. Typically, an event needs to be achieved by some operations, particularly where the operation is intended to achieve a number of different things that require coordination, or how the events in a single use case relate to one another, in particular, use cases where activities may overlap and require coordination.
【翻译】
活动图是UML图中另一个重要的行为图，用于描述系统的动态方面。活动图本质上是流程图的高级版本，可以对从一个活动到另一个活动的流程进行建模。
何时使用活动图
活动图描述了如何协调活动以提供可以处于不同抽象级别的服务。通常，一个事件需要通过某些操作来实现，特别是在该操作旨在实现许多需要协调的不同事物的情况下，或者单个用例中的事件如何相互关联，特别是活动在多个用例中可能会重叠并且需要协调。
【项目中应用】
2.4 actual parameter （实际参数）
【定义】
Synonym: argument
【链接】
|
https://en.wikipedia.org/wiki/Parameter_(computer_programming) |
|
https://java4school.com/actual-and-formal-parameters |
|
https://chortle.ccsu.edu/java5/Notes/chap34A/ch34A_3.html |
【原文】
formal parameter — the identifier used in a method to stand for the value that is passed into the method by a caller.
l For example, amount is a formal parameter of processDeposit
actual parameter — the actual value that is passed into the method by a caller.
l For example, the 200 used when processDeposit is called is an actual parameter.
l actual parameters are often called arguments
【翻译】
形式参数-方法中使用的标识符，代表由调用方传递给方法的值。
例如，数量是processDeposit的形式参数
实际参数-调用方传递给方法的实际值。
例如， 当被进程调用的200 是实际参数。
实际参数通常称为参数
2.5 aggregation （聚合）
【定义】
A special form of association that specifies a whole-part relationship between the aggregate (whole) and a component part. See: composition.
【链接】
|
https://www.guru99.com/association-aggregation-composition-difference.html |
|
https://www.investopedia.com/terms/a/aggregation.asp |
|
https://en.wikipedia.org/wiki/Aggregation |
【原文】
An aggregation is a subtype of an association relationship in UML. Aggregation and composition are both the types of association relationship in UML. An aggregation relationship can be described in simple words as "an object of one class can own or access the objects of another class."
In an aggregation relationship, the dependent object remains in the scope of a relationship even when the source object is destroyed.
UML Aggregation Example:
Let us consider an example of a car and a wheel.
A car needs a wheel to function correctly, but a wheel doesn't always need a car. It can also be used with the bike, bicycle, or any other vehicles but not a particular car. Here, the wheel object is meaningful even without the car object. Such type of relationship is called UML Aggregation relation.
【翻译】
聚合是UML中关联关系的子类型。聚合和组合都是UML中关联关系的类型。聚合关系可以简单地描述为“一个类的对象可以拥有或访问另一类的对象”。
在聚合关系中，即使销毁了源对象，从属对象仍处于关系的范围内。
UML聚合示例：
让我们考虑一个汽车和一个*的例子。
汽车需要车轮才能正常工作，但车轮并不总是需要汽车。它也可以与自行车，自行车或任何其他车辆一起使用，但不能与特定汽车一起使用。在这里，即使没有汽车对象，车轮对象也很有意义。这种类型的关系称为UML聚合关系。
2.6 cardinality （基数）
【定义】
The number of elements in a set.
【链接】
|
https://en.wikipedia.org/wiki/Cardinality |
|
https://brilliant.org/wiki/cardinality/ |
|
https://mathstats.uncg.edu/sites/pauli/112/HTML/section-39.html |
【原文】
In mathematics, the cardinality of a set is a measure of the "number of elements" of the set. For example, the set A={2,4,6} contains 3 elements, and therefore displaystyle A has a cardinality of 3. Beginning in the late 19th century, this concept was generalized to infinite sets, which allows one to distinguish between the different types of infinity, and to perform arithmetic on them.
【翻译】
在数学中，集合的基数是对该集合“元素数”的度量。 例如，集合A = {2,4,6 }包含3个元素，因A的基数为3。从19世纪末开始，该概念被推广为无穷大。 集，从而可以区分不同类型的无穷大，并对它们进行算术运算。
2.7 association class（关联类）
【定义】
A model element that has both association and class properties. An association class can be seen as an association that also has class properties, or as a class that also has association properties.
【链接】
|
https://sparxsystems.com/enterprise_architect_user_guide/15.2/model_domains/associationclass.html |
|
http://etutorials.org/Programming/UML/Chapter+6.+Class+Diagrams+Advanced+Concepts/Association+Class/ |
|
https://wiki.c2.com/?AssociationClass |
【原文】
In some circles, an AssociationClass is a class that contains a map (dictionary) from objects of one class to objects of another class. In others, it encapsulates a single tuple from that dictionary. To understand the difference between the two definitions, consider a Person/Job/Employment scenario. In the AssociationClass-as-tuple camp, basically the UML crowd, there is at most one link (of AssociationClass Employment) between any person and job. Each instance of the AssociationClass is a link. The attributes of the link are properties of the relationship between the specific connected objects. In the case of a binary association, say "employment", between classes Person and Job, we could make the association into an AssociationClass named Employment and add a hireData attribute. In the AssociationClass-as-map camp, there may be many links between person and job; the attributes of each link are usually moved into the associated classes, although it is also possible to model them on a per-link basis in the implementation. People in the tuple camp wonder why such a thing would be useful outside the database world. People in the map camp see AssociationClass as a more explicit way to diagram a QualifiedAssociation.
【翻译】
在某些圈子中，关联类是包含从一个类的对象到另一个类的对象的映射（字典）的类。在其他人中，它封装了该字典中的单个元组。要了解这两个定义的区别，请考虑人员/工作/就业方案。在协会类作为元组阵营，基本上 UML 人群，最多有一个链接（协会类就业）之间的任何人和工作。关联类的每个实例都是一个链接。链接的属性是特定连接对象之间的关系的属性。在类人与工作之间的二进制关联（如"就业"）中，我们可以将关联转换为名为"就业"的关联类，并添加招聘数据属性。在"协会类地图"阵营中，人与工作之间可能有许多联系;每个链接的属性通常移动到关联的类中，尽管在实现中也可以根据每个链接对它们进行建模。元组阵营的人想知道为什么这样的事情在数据库世界之外有用。地图阵营中的人们将关联类视为绘制合格关联的更明确方式。
2.8 association end （关联端）
【定义】
The endpoint of an association, which connects the association to a classifier
【链接】
|
https://www.uml-diagrams.org/association.html |
|
https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/association-end |
|
https://docs.nomagic.com/display/MD183/Association+End |
【原文】
Association end is a connection between the line depicting an association and the icon depicting the connected classifier. Name of the association end may be placed near the end of the line. The association end name is commonly referred to as role name (but it is not defined as such in the UML 2.4 standard). The role name is optional and suppressible.
The idea of the role is that the same classifier can play the same or different roles in other associations. For example, Professor could be an author of some Books or an editor.
Association end could be owned either by
l end classifier, or
l association itself
Association ends of associations with more than two ends must be owned by the association.
【翻译】
关联端是描述关联的线 和描述所连接分类器的图标之间的连接 。关联末端的名称可以放在行尾附近。关联结束名称通常被称为角色名称（但在UML 2.4标准中并未这样定义）。角色名称是可选的，可以抑制。
角色 的想法是，相同的分类器可以在其他关联中扮演相同或不同的角色。例如，教授可以是某些书籍的作者或编辑。
关联端可以由以下任何一个 拥有结束分类，或关联本身
具有两个以上末端的关联的关联末端必须归该关联所有。
2.9 asynchronous action （异步动作）
【定义】
A request where the sending object does not pause to wait for results. Contrast: synchronous action.
【链接】
|
https://medium.com/better-programming/handling-asynchronous-actions-in-redux-86724ed87c6c |
|
https://blog.logrocket.com/managing-asynchronous-actions-in-redux-1bc7d28a00c6/ |
【原文】
As soon as you have to debounce user input, wait for an API response, or cancel an ongoing action, suddenly your application can’t be composed anymore of just the synchronous functions. Synchronous Redux reducer ends up not being enough, because many effects of UI actions are asynchronous, i.e.:
Actions such as “filtering search results” and “retrieving API response” take time and can’t be dispatched immediately,
Actions such as “cancel the ongoing request when the new one is done” need to rely on other actions (not the reducer’s state).
【翻译】
一旦您不得不取消用户输入的抖动，等待API响应或取消正在进行的操作，您的应用程序突然就无法仅由同步功能组成。 同步Redux reducer最终还不够用，因为UI操作的许多效果都是异步的，即：
“过滤搜索结果”和“检索API响应”之类的操作会花费时间，因此无法立即分派，诸如“在完成新请求时取消正在进行的请求”之类的动作需要依赖于其他动作（而不是减速器的状态）。
2.10 behavioral feature （行为特征）
【定义】
A dynamic feature of a model element, such as an operation or method.
【链接】
|
https://sparxsystems.com/enterprise_architect_user_guide/15.2/guidebooks/modeling_behavioral_features.html |
|
https://www.uml-diagrams.org/operation.html |
|
https://dl.acm.org/doi/10.1145/3171592.3171597 |
【原文】
When a system is in operation, Instances of the Blocks that have been defined as part of the architecture and detailed design are instantiated. At this time if a Block has a Classifier Behavior defined this behavior will typically begin and will continue operating until the Block is destroyed. Thus in the example of our Car Park System, when the system has been activated the Card Reader will begin operating and its prime behavior will come into effect. In addition to this a Block (even though fundamentally structural in nature) has behavioral features that will be called upon to carry out work. In summary, there are two fundamental definitions of behavior that are defined within the context of a Block, namely:
l Classifier Behavior - the native behavior that is initiated when a Block is instantiated
l Behavior Features - these are the Operations and Receptions (and their related Signals)
【翻译】
当系统运行时，将实例化已定义为体系结构和详细设计一部分的块实例。 此时，如果某个块定义了“分类器行为”，则此行为通常将开始并且将继续运行，直到该块被销毁为止。 因此，在我们的停车场系统示例中，当系统启动后，读卡器将开始运行，并且其主要行为将生效。 除此之外，“块”（即使本质上是基本结构的）具有行为特征，将被要求进行工作。 总之，在块的上下文中定义了行为的两个基本定义，即：
l 分类器行为-实例化块时启动的本机行为
l 行为特征-这些是操作和接收（及其相关信号）
3 CH3
3.1 Entity-relationship model（实体关系模型）
【定义】
A model of data that are relevant for a system, or of the data of an application domain.
【链接】
|
https://www.w3schools.in/dbms/er-model/ |
【原文】
ER-Diagram is a pictorial representation of data that describes how data is communicated and related to each other. Any object, such as entities, attributes of an entity, sets of relationship, and other attributes of relationship, can be characterized with the help of the ER diagram.
【翻译】
ER图是数据的图形表示，描述了数据如何通信以及如何相互关联。 任何对象，例如实体，实体的属性，关系集以及其他关系属性，都可以借助ER图来表征。
3.2 Sequence diagram（时序图）
【定义】
A diagram type in UML which models the interactions between a selected set of objects and/or actors in the sequential order that those interactions occur.
【链接】
|
https://www.smartdraw.com/sequence-diagram/ |
|
https://www.geeksforgeeks.org/unified-modeling-language-uml-sequence-diagrams/ |
|
https://www.javatpoint.com/uml-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
【翻译】
顺序图根据消息随时间的交换来描述类之间的交互。 它们也称为事件图。 序列图是可视化和验证各种运行时场景的好方法。 这些可以帮助预测系统的行为方式并发现班级在对新系统进行建模的过程中可能需要承担的责任
【应用】
3.3 Structured Analysis（结构分析）
【定义】
An approach for specifying the functionality of a system based on a hierarchy of dataflow diagrams.
【链接】
|
https://www.geeksforgeeks.org/structured-analysis-and-structured-design-sa-sd/ |
|
https://ecomputernotes.com/software-engineering/what-do-you-mean-by-structured-analysis |
|
https://www.wisegeek.com/what-is-structured-analysis.htm |
【原文】
The structured analysis technique uses function-based decomposition while modeling the problem. It focuses on the functions performed in the problem domain and the data consumed and produced by these functions.
The structured analysis method helps the analyst decide what type of information to obtain at different points in analysis, and it helps organize information so that the analyst is not overwhelmed by the complexity of the problem.
It is a top-down refinement approach, which was originally called structured analysis and specification and was proposed for producing the specifications. However, we will limit our attention to the analysis aspect of the approach. Before we describe the approach, let us describe the data flow diagram and data dictionary on which the technique relies heavily.
Data Flow Diagrams and Data Dictionary
Data flow diagrams (also called data flow graphs) are commonly used during problem analysis. Data flow diagrams (DFDs) are quite general and are not limited to problem analysis for software engineering discipline. DFDs are very useful in understanding a system and can be effectively used during analysis.
A DFD shows the flow of data through a system. It views a system as a function that transforms the inputs into desired outputs. Any complex system will not perform this transformation in a “single step”, and data will typically undergo a series of transformations before it becomes the output.
The DFD aims to capture the transformation that take place within a system to the input data so that eventually the output data is produced. The agent that performs the transformation of data from one state to another is called a process (or a bubble). So, a DFD shows the movement of data through the different transformations or processes in the system.
The processes are shown by named circles and data flows are represented by named arrows entering or leaving the bubbles. A rectangle represents a source or sink and is a pet originator or consumer of data. A source or sink is typically outside the main system of study. An example of a DFD for a system that pays workers.
In this DFD there is one basic input data flow, the weekly timesheet, which originates from the source worker. His basic output is the paycheck, the sink for which is also the worker, In this system, first the employee’s record is retrieved, using the employee ID, which is contained in the timesheet.
From the employee record, the rate of payment and overtime are obtained. These rates and the regular and overtime hours (from the timesheet) are used to compute the pay. After the total pay the tax-rate file is used. The amount of tax deducted is recorded in the employee and company records. Finally, the payback is issued for the net pay. The amount paid is also recorded in company records.
This DFD is an abstract description of the system for handling payment. It does not matter if the system is automated or manual. This diagram could very well be for a manual system where the computations are all done with calculators and not represented in this DFD.
For example, what happens if the error in the weekly timesheet is not shown in this DFD. This is done to avoid getting bogged down with details while constructing a DFD for the overall system. If more details are desired, the DFD can be further refined.
It should be pointed out that a DFD is not a flowchart. A DFD represents the flow of data. While a flowchart shows the flow of control, a DFD does not represent procedural information. So, while drawing a DFD, one must not get involved in procedural details, and procedural thinking must be consciously avoided.
For example, considerations of loops and decisions must be ignored. In drawing the DFD, the designer has to specify the major transforms in the path of the data flowing.
While analyzing the problem domain the problem can be partitioned with respect to its functionality or with respect to objects. Object oriented modeling for (object-oriented analysis) uses the latter approach. During analysis, an object represents some entity or some concept in the problem domain.
An object contains some state information and provides some services to entities outside the objects. The state of the object can be accessed or modified only through the services they provide. Some objects also interact with the users through their services such that the users get the desired services.
Hence the goal of modeling is to identify the objects that exist in the problem domain, define the objects by specifying what state information they encapsulate and what services they provide, and identify relationships that exist between objects, such that the overall model is such that it supports the desired user services. Such a model of a system is called its object model.
【翻译】
结构化分析技术在对问题建模时使用基于函数的分解。它着重于在问题域中执行的功能以及这些功能消耗和产生的数据。
结构化分析方法可帮助分析师确定要在分析的不同点上获取哪种类型的信息，并有助于组织信息，从而使分析师不会因问题的复杂性而感到不知所措。
这是一种自上而下的细化方法，最初称为结构化分析和规范，并被提议用于生成规范。但是，我们将注意力集中在该方法的分析方面。在描述该方法之前，让我们描述该技术高度依赖的数据流程图和数据字典。
数据流程图和数据字典
问题分析期间通常使用数据流程图（也称为数据流程图）。数据流程图（DFD）非常通用，不限于软件工程学科的问题分析。DFD对理解系统非常有用，可以在分析过程中有效使用。
DFD显示通过系统的数据流。它将系统视为将输入转换为所需输出的功能。任何复杂的系统都不会在“单个步骤”中执行此转换，并且数据通常会在变为输出之前经历一系列转换。
DFD旨在捕获系统内对输入数据的转换，从而最终生成输出数据。将数据从一种状态转换为另一种状态的代理称为流程（或气泡）。因此，DFD通过系统中的不同转换或过程显示数据的移动。
该过程由命名圆圈表示，数据流由进入或离开气泡的命名箭头表示。矩形代表源或汇，是数据的原始创建者或使用者。源或汇通常在主要学习系统之外。用于支付工人工资的系统的DFD示例。
在该DFD中，有一个基本的输入数据流，即每周时间表，它是源工作人员提供的。他的基本输出是薪水，工资也是薪水的接收者。在此系统中，首先使用时间表中包含的员工ID来检索员工的记录。
从员工记录中，获取付款率和加班费。这些费率以及正常和加班时间（来自时间表）用于计算工资。在支付总额之后，使用税率文件。扣除的税额记录在员工和公司记录中。最后，为净工资发出投资回收期。支付的金额也记录在公司记录中。
该DFD是用于处理付款的系统的抽象说明。系统是自动还是手动都没有关系。该图非常适合用于手动系统，其中所有计算均使用计算器完成，并且未在此DFD中表示。
例如，如果该DFD中未显示每周时间表中的错误，该怎么办。这样做是为了避免在为整个系统构建DFD时陷入细节。如果需要更多详细信息，可以进一步完善DFD。
应该指出的是，DFD不是流程图。DFD代表数据流。虽然流程图显示了控制流程，但DFD并不代表过程信息。因此，在绘制DFD时，一定不要参与程序细节，并且必须有意识地避免程序思考。
例如，必须忽略循环和决策的考虑。在绘制DFD时，设计人员必须指定数据流路径中的主要变换。
在分析问题域时，可以根据其功能或对象来划分问题。用于（面向对象分析）的面向对象建模使用后一种方法。在分析过程中，对象代表问题领域中的某个实体或某个概念。
对象包含一些状态信息，并为对象外部的实体提供某些服务。只能通过对象提供的服务来访问或修改对象的状态。一些对象还通过其服务与用户交互，从而使用户获得所需的服务。
因此，建模的目的是识别存在于问题域中的对象，通过指定它们封装的状态信息以及它们提供的服务来定义对象，并标识对象之间存在的关系，从而使整个模型成为现实。支持所需的用户服务。这样的系统模型称为其对象模型。
3.4 Dataflow diagram（数据流图）
【定义】
A coarse description of the required capabilities of a system from the customer's perspective.
【链接】
|
https://www.visual-paradigm.com/tutorials/data-flow-diagram-dfd.jsp |
|
https://123projectlab.com/data-flow-diagram-symbols-and-examples/ |
【原文】
What is a data flow diagram (DFD)?
A picture is worth a thousand words. A Data Flow Diagram (DFD) is a traditional way to visualize the information flows within a system. A neat and clear DFD can depict a good amount of the system requirements graphically. It can be manual, automated, or a combination of both.
It shows how information enters and leaves the system, what changes the information and where information is stored. The purpose of a DFD is to show the scope and boundaries of a system as a whole. It may be used as a communications tool between a systems analyst and any person who plays a part in the system that acts as the starting point for redesigning a system.
It is usually beginning with a context diagram as level 0 of the DFD diagram, a simple representation of the whole system. To elaborate further from that, we drill down to a level 1 diagram with lower-level functions decomposed from the major functions of the system. This could continue to evolve to become a level 2 diagram when further analysis is required. Progression to levels 3, 4 and so on is possible but anything beyond level 3 is not very common. Please bear in mind that the level of detail for decomposing a particular function depending on the complexity that function.
【翻译】
什么是数据流图 （DFD）？
一张图片胜过千言万语。数据流图 （DFD） 是一种将系统内的信息流可视化的传统方法。整洁清晰的 DFD 可以以图形方式描绘大量系统需求。它可以是手动的、自动的，也可以是两者的组合。
它显示信息如何进入和离开系统，什么更改信息以及信息的存储位置。DFD 的目的是显示整个系统的范围和边界。它可以用作系统分析师和在系统中扮演角色的任何人之间的通信工具，而作为重新设计系统的起点。
它通常以上下文图作为 DFD 关系图的级别 0 开头，这是整个系统的简单表示形式。为了进一步阐述，我们深入到一级图，从系统的主要功能分解为较低级别的函数。当需要进一步分析时，这可能会继续演变为 2 级图。进展到3级，4级等是可能的，但任何超出3级不是很常见。请记住，分解特定函数的详细信息级别取决于该函数的复杂性。
3.5 Context diagram（范围图）
【定义】
A diagrammatic representation of a context model. In Structured Analysis, the context diagram is the root of the dataflow diagram hierarchy.
【链接】
|
https://www.sciencedirect.com/topics/computer-science/context-diagram |
|
https://ryanstutorials.net/software-design-and-development/context-diagrams.php |
|
https://www.modernanalyst.com/Careers/InterviewQuestions/tabid/128/ID/1433/What-is-a-Context-Diagram-and-what-are-the-benefits-of-creating-one.aspx |
【原文】
A context diagram consists of a circle in the center which represents your system. Around the outside are rectangles which represent the external entities that your system has to interact with. External entities could be a person, or another business, a system etc. Joining the external entities to your system are lines with arrows labelled with what data is transferred (or flows). These Data flows (sometimes referred to as relationships) are any piece of data (or information) which moves between your system and an external entity.
【翻译】
上下文图由中心的圆圈组成，代表您的系统。外部周围是矩形，这些矩形代表系统必须与之交互的外部实体。外部实体可以是个人，也可以是其他公司，系统等。将外部实体连接到系统的是带有箭头的线，上面标有要传输（或流动）哪些数据。这些数据流（有时称为关系）是在系统与外部实体之间移动的任何数据（或信息）。
3.6 Use case diagram（用例图）
【定义】
A diagram type in UMLthat models the actors and the use cases of a system.
【链接】
|
https://creately.com/blog/diagrams/use-case-diagram-tutorial/ |
|
https://www.lucidchart.com/pages/uml-use-case-diagram |
【原文】
A use case diagram is a way to summarize details of a system and the users within that system. It is generally shown as a graphic depiction of interactions among different elements in a system. Use case diagrams will specify the events in a system and how those events flow, however, use case diagram does not describe how those events are implemented.
A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. In this context, the term "system" refers to something being developed or operated, such as a mail-order product sales and service Web site. Use case diagrams are employed in UML (Unified Modeling Language), a standard notation for the modeling of real-world objects and systems. There are a number of benefits with having a use case diagram over similar diagrams such as flowcharts.
Use case diagram uses
The reasons why an organization would want to use case diagrams include:
Represent the goals of systems and users.
Specify the context a system should be viewed in.
Specify system requirements.
Provide a model for the flow of events when it comes to user interactions.
Provide an outside view of a system.
Show’s external and internal influences on a system.
【翻译】
用例图是汇总系统和系统中用户详细信息的一种方式。它通常显示为系统中不同元素之间交互的图形描述。用例图将指定系统中的事件以及这些事件的流速，但是用例图没有描述这些事件是如何实现的。
用例是系统分析中用于识别、澄清和组织系统需求的方法。在此上下文中，"系统"一词是指正在开发或操作的内容，例如邮购产品销售和服务网站。用例图用于 UML（统一建模语言），这是实际对象和系统建模的标准表示法。在流程图等类似关系图上使用用例图有很多好处。
用例图使用
组织想要使用案例关系图的原因包括：
表示系统和用户的目标。
指定应查看系统的上下文。
指定系统要求。
在用户交互方面为事件流提供模型。
提供系统的外部视图。
显示对系统的外部和内部影响。
【项目中应用】
3.7 System boundary（系统边界）
【定义】
The boundary between a system and its surrounding Tcontext.
【链接】
|
https://sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/systemboundary.html |
|
https://insights.sei.cmu.edu/insider-threat/2018/09/cybersecurity-architecture-part-2-system-boundary-and-boundary-protection.html |
|
https://www.cs.uct.ac.za/mit_notes/software/htmls/ch01s04.html |
【原文】
To properly identify an information system's boundary, you must identify not only where the data is stored, but also where system data flows, as well as critical dependencies.
A too-narrow boundary could exclude system resources from the level of protection required by the system owner. Boundaries are often too narrowly scoped and exclude critical dependencies--systems that could have a direct impact on the confidentiality, integrity, and availability of the high-value system being reviewed. If there are critical dependencies outside the boundary and they could affect the CIA of the system, you must account for the additional risk.
With a defined system boundary, the organization should have a well-defined and documented diagram depicting of all of the entities that store or process system data.
【翻译】
要正确识别信息系统的边界，您不仅必须确定数据的存储位置，还要标识系统数据流的位置以及关键依赖项。
过窄的边界可能会将系统资源排除在系统所有者所需的保护级别之外。边界的范围往往过于狭窄，排除了关键依赖关系，这些系统可能直接影响到所审查的高价值系统的机密性、完整性和可用性。如果边界之外存在关键依赖关系，并且它们可能会影响系统的 CIA，则必须考虑额外的风险。
使用定义的系统边界，组织应具有定义明确且有文档记录的图表，描述存储或处理系统数据的所有实体。
3.8 Acceptance test（验收测试）
【定义】
ACCEPTANCE TESTING is a level of software testing where a system is tested for acceptability.
【链接】
|
https://softwaretestingfundamentals.com/acceptance-testing/#:~:text=%20Acceptance%20Testing%20%201%20Analogy.%20During%20the,it%20is%20advised%20specially%20for%20Internal...%20More%20 |
|
https://www.softwaretestinghelp.com/what-is-acceptance-testing/ |
【原文】
What is Acceptance Testing?
Once the System Testing process is completed by the testing team and is signed-off, the entire Product/application is handed over to the customer/few users of customers/both, to test for its acceptability i.e., Product/application should be flawless in meeting both the critical and major Business requirements. Also, end-to-end business flows are verified similar as in real-time scenario.
The production-like environment will be the testing environment for Accepting Testing (Usually termed as Staging, Pre-Prod, Fail-Over, UAT environment).
This is a black-box testing technique where only the functionality is verified to ensure that the product meets the specified acceptance criteria (no need for design/implementation knowledge).
Why Acceptance Tests?
Though System testing has been completed successfully, the Acceptance test is demanded by the customer. Tests conducted here are repetitive, as they would have been covered in System testing.
Then, why is this testing is conducted by customers?
This is because:
- To gain confidence in the product that is getting released to the market.
- To ensure that the product is working in the way it has to.
- To ensure that the product matches current market standards and is competitive enough with the other similar products in the market.
Types
#1) User Acceptance Testing (UAT)
UAT is to assess whether the Product is working for the user, correctly for the usage. Specific requirements which are quite often used by the end-users are primarily picked for the testing purpose. This is also termed as End-User Testing.
The term “User” here signifies the end-users to whom the Product/application is intended and hence, testing is performed from the end-users perspective and from their point of view.
#2) Business Acceptance Testing (BAT)
This is to assess whether the Product meets the business goals and purposes or not.
BAT mainly focuses on business benefits (finances) which are quite challenging due to the changing market conditions/advancing technologies so that the current implementation may have to undergo changes which result in extra budgets.
Even the Product passing the technical requirements may fail BAT due to these reasons.
#3) Contract Acceptance Testing (CAT)
This is a contract which specifies that once the Product goes live, within a predetermined period, the acceptance test must be performed and it should pass all the acceptance use cases.
Contract signed here is termed as Service Level Agreement (SLA), which includes the terms where the payment will be made only if the Product services are in-line with all the requirements, which means the contract is fulfilled.
Sometimes, this contract may happen before the Product goes live. Either the ways, a contract should be well defined in terms of the period of testing, areas of testing, conditions on issues encountered at later stages, payments, etc.
#4) Regulations/Compliance Acceptance Testing (RAT)
This is to assess whether the Product violates the rules and regulations that are defined by the government of the country where it is being released. This may be unintentional but will impact negatively on the business.
Usually, the developed Product/application that is intended to be released all over the world, has to undergo RAT, as different countries/regions have different rules and regulations defined by its governing bodies.
If any of the rules and regulations are violated for any country, then that country or the specific region in that country will not be allowed to use the Product and is considered as a Failure. Vendors of the Product will be directly responsible if the Product is released even though there is a violation.
#5) Operational Acceptance Testing (OAT)
This is to assess the operational readiness of the Product and is a non-functional testing. It mainly includes testing of recovery, compatibility, maintainability, technical support availability, reliability, fail-over, localization etc.
OAT mainly assures the stability of the Product before releasing it to the production.
#6) Alpha Testing
This is to assess the Product in the development/testing environment by a specialized testers team usually called alpha testers. Here, the testers feedback, suggestions help to improve the Product usage and also to fix certain bugs.
Here, testing happens in a controlled manner.
#7) Beta Testing/Field Testing
This is to assess the Product by exposing it to the real end-users, usually called beta testers/beta users, in their environment. Continuous feedback from the users is collected and the issues are fixed. Also, this helps in enhancing/improving the Product to give a rich user experience.
Testing happens in an uncontrolled manner, which means a user has no restrictions on the way in which the Product is being used.
【翻译】
什么是验收测试？
一旦测试团队完成系统测试流程并签字，整个产品/应用程序将移交给客户/少数客户/两者，以测试其可接受性，即产品/应用程序在满足关键和主要业务需求方面应完美无瑕。此外，端到端业务流验证与实时方案类似。
生产环境是接受测试的测试环境（通常称为暂存、预生产、故障转移、UAT 环境）。
这是一种黑盒测试技术，其中仅验证功能，以确保产品满足指定的验收标准（无需设计/实现知识）。
为什么要进行验收测试？
虽然系统测试已成功完成，但客户要求进行验收测试。此处执行的测试是重复的，因为它们在系统测试中已经涵盖。
那么，为什么这个测试是由客户进行的呢？
这是因为：
• 获得对正在推向市场的产品的信心。
• 确保产品以必须的方式工作。
• 确保产品符合当前市场标准，并且与市场上其他同类产品具有足够的竞争力。
类型
#1） 用户验收测试 （UAT）
UAT 是评估产品是否为用户工作，正确用于使用。最终用户经常使用的特定要求主要用于测试目的。这也称为最终用户测试。
此处的术语"用户"表示产品/应用程序所针对的最终用户，因此，测试是从最终用户的角度和角度执行的。
#2） 业务验收测试 （BAT）
这是为了评估产品是否符合业务目标和目的。
BAT 主要关注业务收益（财务），由于市场条件/先进技术的不断变化，这些收益（财务）极具挑战性，因此当前实施可能必须发生变更，从而产生额外的预算。
由于这些原因，即使通过技术要求的产品也可能因这些原因而失败 BAT。
#3） 合同验收测试 （CAT）
这是一项合同，规定一旦产品上线，在预定的期间内，必须执行验收测试，并且应通过所有验收用例。
此处签署的合同称为服务级别协议 （SLA），其中包括仅在产品服务符合所有要求（这意味着合同已履行）时付款的条款。
有时，此合同可能发生在产品上线之前。无论是通过哪种方式，合同都应在测试期、测试领域、后期阶段遇到的问题的条件、付款等方面进行明确界定。
#4） 法规/合规验收测试 （RAT）
这是为了评估产品是否违反了发布该产品的国家/地区*定义的规则和法规。这可能是无意的，但会对业务产生负面影响。
通常，要在世界各地发布的开发产品/应用程序必须经过 RAT，因为不同的国家/地区有不同的规则和法规，由其理事机构定义。
如果任何国家/地区违反任何规则和法规，则不允许该国家/地区或该国/地区的特定区域使用本产品，并被视为失败。如果产品发布，即使存在违规行为，产品供应商也将直接负责。
#5） 操作验收测试 （OAT）
这是为了评估产品的运行准备情况，并且是一种非功能性测试。主要包括恢复、兼容性、可维护性、技术支持可用性、可靠性、故障转移、本地化等测试。
OAT 在将产品发布到生产中之前，主要确保产品的稳定性。
#6） 阿尔法测试
这是由专门测试团队（通常称为 Alpha 测试人员）在开发/测试环境中评估产品。在这里，测试人员的反馈，建议有助于提高产品使用，并修复某些错误。
在这里，测试以受控方式进行。
#7） 测试版测试/现场测试
这是通过向环境中真正的最终用户（通常称为 beta 测试人员/beta 用户）公开产品来评估产品。收集用户的连续反馈并修复问题。此外，这有助于增强/改进产品，提供丰富的用户体验。
测试以不受控制的方式进行，这意味着用户对产品的使用方式没有限制。
3.9 containment hierarchy（包含层次结构）
【定义】
A namespace hierarchy consisting of model elements.andthe containment relationships that exist between them. Acontainment hierarchy forms an acyclic graph.
【链接】
|
http://www.firstobject.com/dn_markhierarchy.htm |
|
https://www.sciencedirect.com/topics/computer-science/containment-hierarchy |
|
http://www.web-feats.com/classes/javaprog/lessons/swing_gui_intro/containment.htm |
【原文】
All Swing GUI applications and applets make use of a containment hierarchy that is more or less unrelated to (or at least different from) the Swing components' position on the class hierarchy.
The containment hierarchy, from top to bottom, is as follows:
Top-level Container(s)
To appear onscreen, every GUI component must be part of a containment hierarchy. There is at least one containment hierarchy in every program that uses Swing components. Each containment hierarchy has a top-level container at its root.
Intermediate Container(s)
Generally speaking, an intermediate container consists of a content pane, or panel, that contains all the visible (atomic) components. Each top-level container must contain at least one intermediate container if there is to be anything useful displayed on the screen.
Atomic Component(s)
The button and label are atomic components - self-sufficient entities that present bits of information to the user. Often, atomic components also get input from the user.
【翻译】
所有 Swing GUI 应用程序和小子都使用与 Swing 组件在类层次结构中的位置或多或少无关（或至少不同于）的包含层次结构。
包含层次结构从上到下如下所示：
*容器
要在屏幕上显示，每个 GUI 组件都必须是包含层次结构的一部分。每个程序中至少有一个使用 Swing 组件的包含层次结构。每个包含层次结构的根级都有一个*容器。
中间容器
一般来说，中间容器由包含所有可见（原子）组件的内容窗格或面板组成。如果屏幕上显示任何有用内容，每个*容器必须至少包含一个中间容器。
原子组件
按钮和标签是原子组件 - 向用户显示信息位的自给自足实体。通常，原子组件也会从用户获取输入。
3.10 Activity diagram（活动图）
【定义】
Activity diagram is another important behavioral diagram in UML diagram to describe dynamic aspects of the system.
【链接】
【原文】
What is an Activity diagram?
A UML activity diagram helps to visualize a certain use case at a more detailed level. It is a behavioral diagram that illustrates the flow of activities through a system.
UML activity diagrams can also be used to depict a flow of events in a business process. They can be used to examine business processes in order to identify its flow and requirements.
Activity Diagram Symbols
UML has specified a set of symbols and rules for drawing activity diagrams. Following are the commonly used activity diagram symbols with explanations.
Activity Diagrams with Swimlanes
In activity diagrams swimlanes– also known as partitions – are used to represent or group actions carried out by different actors in a single thread. Here are a few tips you can follow when using swimlanes.
- Add swimlanes to linear processes. It makes it easy to read.
- Don’t add more than 5 swimlanes.
- Arrange swimlanes in a logical manner.
How to Draw an Activity Diagram
Activity diagrams can be used to model business requirements, create a high-level view of a system’s functionalities, analyze use cases and for various other purposes. In each of these cases, here’s how to draw an activity diagram from the beginning.
Step 1: Figure out the action steps from the use case
Here you need to identify the various activities and actions your business process or system is made up of.
Step 2: Identify the actors who are involved
If you already have figured out who the actors are, then it’s easier to discern each action they are responsible for.
Step 3: Find a flow among the activities
Figure out in which order the actions are processed. Mark down the conditions that have to be met in order to carry out certain processes, which actions occur at the same time and whether you need to add any branches in the diagram. And do you have to complete some actions before you can proceed to others?
Step 4: Add swimlanes
You have already figured out who is responsible for each action. Now it’s time to assign them a swimlane and group each action they are responsible for under them.
【翻译】
什么是活动图？
UML 活动图有助于在更详细的级别可视化特定用例。它是一个行为图，用于说明通过系统的活动流。
UML 活动图还可用于描述业务流程中的事件流。它们可用于检查业务流程，以确定其流程和要求。
活动图符号
UML 为绘制活动图指定了一组符号和规则。以下是常用的活动图符号，并配有说明。
带泳道的活动图
在活动图中，游线（也称为分区）用于表示或分组由单个线程中的不同参与者执行的操作。以下是使用泳道时可以遵循的一些提示。
• 将泳道添加到线性过程。它便于阅读。
• 不要添加超过 5 条泳道。
• 以合乎逻辑的方式安排泳道。
如何绘制活动图
活动图可用于对业务需求进行建模、创建系统功能的高级别视图、分析用例以及用于各种其他目的。在每种情况下，下面都提供如何从头开始绘制活动图。
第 1 步：从用例中找出操作步骤
在这里，您需要确定业务流程或系统由各种活动和操作。
第 2 步：确定参与者
如果你已经搞清楚了谁是演员，那么更容易辨别他们负责的每个动作。
第 3 步：在活动之间查找流程
找出操作处理的顺序。向下标记执行某些过程必须满足的条件、同时执行哪些操作以及是否需要在关系图中添加任何分支。你一定先完成一些行动，然后才能继续做其他行动吗？
第 4 步：添加泳道
您已经计算出谁应对每个操作负责。现在是给他们分配一个泳道，并分组他们负责的每个动作。1.2验收测试（Acceptance test）
【项目中应用】
4 CH4
4.1 collaboration diagram（合作图）
【定义】
A diagram that shows interactions organized around the structure of a model, using either classifiers and associations or instances and links. Unlike a sequence diagram, a collaboration diagram shows the relationships among the instances. Sequence diagrams and collaboration diagrams express similar information, but show it in different ways. See: sequence diagram.
【链接】
|
https://www.techopedia.com/definition/16467/collaboration-diagram |
【原文】
Use a collaboration diagram (collaboration diagram: An interaction diagram that shows, for one system event described by one use case, how a group of objects collaborates with each other.) to show relationships among object roles such as the set of messages exchanged among the objects to achieve an operation or result.
UML Collaboration diagrams (interaction diagrams) illustrate the relationship and interaction between software objects. They require use cases, system operation contracts, and domain models to exist already. The collaboration diagram demonstrates the transmission of messages between classes and objects (instances). It is created for each system operation that relates to the current development cycle (iteration).
When creating collaboration diagrams, patterns are used to justify relationships. Patterns are the best principles for assigning responsibilities to objects and are described further in the section on patterns. There are two main types of patterns used for assigning responsibilities which are evaluative patterns and driving patterns.
【翻译】
使用协作关系图（协作关系：对于一个用例描述的一个系统事件，显示一组对象如何相互协作）来显示对象角色之间的关系，例如对象之间交换的消息集，以实现操作或结果。
UML 协作图（交互图）说明了软件对象之间的关系和交互。它们要求用例、系统操作协定和域模型已经存在。协作图演示了类和对象（实例）之间的消息传输。它为与当前开发周期（迭代）相关的每个系统操作创建。
创建协作关系图时，模式用于证明关系的合理性。模式是将责任分配给对象的最佳原则，并在有关模式的部分中进一步介绍。有两种主要模式用于分配职责，即评估模式和驱动模式。
4.2 Steering committee(指导委员会)
【定义】
A committee that supervises a project
【链接】
【原文】
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.
At times, steering committees have been known to get too involved with the projects they are supposed to be providing oversight for, and they begin to take an overly active role in the management of the project. When this occurs, someone on or off the committee must remind the steering committee of its advisory role in the project, directing the focus back onto the project itself and what needs to be done to bring it to a successful conclusion.
【翻译】
指导委员会的职能是为他们监督的项目提供支持，倡导和支持。指导委员会并非旨在实际管理或运行项目的，因此应避免这样做。相反，指导委员会应促进项目经理规划和指导给定项目的能力，并在此过程中提供建议和支持。
明确界定其职责范围和宗旨后，指导委员会才能发挥最佳作用。他们通常充当决策机构，确定所监督项目的预算，时间表和人员。指导委员会不应由不需要的成员组成；相反，委员会中的每个成员都应具有与监督，决策记录，预算或取决于项目所需的其他特定技能相关的特定职能。
有时，众所周知，指导委员会过多地参与了他们本应提供监督的项目，并且开始在项目管理中扮演过积极的角色。发生这种情况时，委员会上下的人员必须提醒指导委员会其在项目中的顾问作用，将重点重新指向项目本身以及需要做什么才能使其成功完成。
4.3 Inspection(检查)
【定义】
A kind of review where the artifact under review is inspected by a
【链接】
|
https://dictionary.cambridge.org/dictionary/english/inspection |
|
https://www.agilealliance.org/glossary/xp/ |
【原文】
Domain modeling is one of two basic approaches to application design. On a basic level, domain modeling can be understood by taking “domain” to mean the sum total of the knowledge of the business and “modeling” to mean an object-oriented abstraction of the business logic. After constructing a domain model consisting of different objects based on the business requirements, the architect then writes code to carry out the business logic between the objects.
No one-size-fits-all solution exists among these options. The most suitable approach depends on the complexity of the business requirements. For example, using the domain model for a query-and-report process is unnecessarily complicated. In cases like this, it helps to recognize simplicity for what it is, get rid of the domain layers, and gain direct access to the infrastructure layer.
Domain modeling offers the option to build more robust, scalable, and user-friendly applications when dealing with complex business logic. The issue, then, is identifying when to use this approach, and learning how to apply it effectively.
【翻译】
域建模是应用程序设计的两种基本方法之一。在基本层面上，域建模可以通过将"域"理解为业务知识的总和，而将域建模理解为业务逻辑面向对象的抽象。在基于业务需求构建由不同对象组成的域模型后，架构师然后编写代码以在对象之间执行业务逻辑。
这些选项中不存在一刀切的解决方案。最合适的方法取决于业务需求的复杂性。例如，将域模型用于查询和报告过程是不必要的复杂。在这种情况下，它有助于识别简单性，摆脱域层，并直接访问基础结构层。
在处理复杂的业务逻辑时，域建模提供了构建更健壮、可扩展和用户友好的应用程序的选项。因此，问题是确定何时使用这种方法，并学习如何有效地应用这种方法。
【项目中应用】
4.4 postcondition（后置条件）
【定义】
A constraint that must be true at the completion of an
operation.
【链接】
|
https://www.tutorialspoint.com/software_testing_dictionary/post_condition.htm |
|
https://www.sciencedirect.com/topics/computer-science/postconditions |
【原文】
In computer programming, a postcondition is a condition or predicate that must always be true just after the execution of some section of code or after an operation in a formal specification. Postconditions are sometimes tested using assertions within the code itself. Often, postconditions are simply included in the documentation of the affected section of code.
For example: The result of a factorial is always an integer and greater than or equal to 1. So a program that calculates the factorial of an input number would have postconditions that the result after the calculation be an integer and that it be greater than or equal to 1. Another example: a program that calculates the square root of an input number might have the postconditions that the result be a number and that its square be equal to the input.
【翻译】
在计算机程序设计中，后置条件是紧接在执行某些代码部分之后或在正式说明中进行操作之后必须始终为真的条件或谓词。有时使用代码本身内的断言来测试后置条件。通常，后置条件仅包含在代码的受影响部分的文档中。
例如：阶乘的结果始终是整数且大于或等于1。因此，计算输入数字的阶乘的程序将具有后置条件，即计算后的结果为整数并且大于或等于。等于1。另一个示例：计算输入数字的平方根的程序可能会有后置条件，即结果是数字，并且其平方等于输入。
4.5 Block Definition Diagram(块定义图)
【定义】
When describing your system structure, you should start from defining Blocks in SysML Block Definition Diagram. Blocks represent the system hierarchy in terms of systems and subsystems. You can model either the logical or physical decomposition of a system, and the specification of software, hardware, or human elements.
【链接】
|
https://sysml.org/sysml-faq/what-is-block-definition-diagram.html#:~:text=Block%20Definition%20Diagram%20%28bdd%29%3A%20A%20Block%20Definition%20Diagram,their%20contents%20%28Properties%2C%20Behaviors%2C%20Constraints%29%2C%20Interfaces%2C%20and%20relationships. |
|
https://www.sciencedirect.com/topics/computer-science/block-definition-diagram |
|
https://docs.nomagic.com/display/SYSMLP190/Defining+Blocks+in+Block+Definition+Diagram |
【原文】
A Block Definition Diagram is a static structural diagram that shows system components, their contents (Properties, Behaviors, Constraints), Interfaces, and relationships.
Blocks can be recursively decomposed ("nested") into Parts by alternating between Block Definition Diagram (BDD) definitions and Internal Block Diagram (IBD) usages (See Usage Notes below.)
Behaviors can either be encapsulated by Blocks (e.g., Operations, Signals, and State Machines) or Allocated (via «allocate» Dependency) to Blocks (e.g., Activities/Actions) directly or indirectly (via Interfaces).
Blocks can be mathematically constrained via Constraint Blocks to produce mathematically simulatable Parametric diagrams.
compare and contrast: UML 2 Class and Component diagrams; SA/SD System Context & Structure Chart diagrams; IDEF IDEF1X diagrams.
Purpose
The purpose of Block Definition Diagrams is to specify system static structures that be used for Control Objects, Data Objects, and Interface Objects. When properly applied (See Usage Notes below) Block diagrams are recursively scalable and mathematically (parametrically) simulatable (See Executable Semantics below.)
【翻译】
块定义图是一个静态结构图，它显示系统组件，它们的内容（属性，行为，约束），接口和关系。
可以通过在块定义图（BDD）定义和内部块图（IBD）用法之间交替来将块递归分解（嵌套）为零件（请参见下面的用法说明）。
行为可以由块（例如，操作，信号和状态机）封装，也可以直接（或通过接口）间接（通过“ allocate”依赖）分配给块（例如，活动/动作）。
可以通过约束块对块进行数学约束，以生成数学上可模拟的参数图。
比较和对比：UML 2类和组件图；SA / SD系统上下文和结构图图; IDEF IDEF1X图表。
目的
块定义图的目的是指定用于控制对象，数据对象和接口对象的系统静态结构。正确应用后（请参见下面的使用说明），框图可以递归地缩放，并且可以在数学上（参数上）模拟（请参见下面的可执行语义）。
4.6 Requirement Diagram（需求图)
【定义】
A requirement specifies a capability or condition that must (or should) be satisfied.
要求指定必须（或应该）满足的能力或条件。
【链接】
【原文】
Requirement: A Requirement (notation: rectangle with «requirement» keyword) is a capability or condition that a system must ("shall") satisfy. A Functional Requirement (functionalRequirement» keyword) specifies a function that a system must perform, whereas a Non-Functional Requirement (NFR) specifies quality criteria that can be used to test the effectiveness of system functions.
SysML predefines the following stereotype specializations of NFRs:
«performanceRequirement»
«interfaceRequirement»
«designConstraint»
«physicalRequirement»
Requirement diagram (req): A SysML Requirement diagram is a static structural diagram that shows the relationships among Requirement («requirement») constructs, model elements that Satisfy («satisfy» Dependency) them, and Test Cases that Verify («verify» Dependency) them.
Purpose
The purpose of Requirement diagrams is to specify both Functional and Non-Functional Requirements within the model so that they can be traced to other model elements that Satisfy them and Test Cases that Verify them.
【翻译】
要求：要求（符号：带 [要求] 关键字的矩形）是系统必须满足的功能或条件。功能要求（功能要求+ 关键字）指定系统必须执行的功能，而非功能要求 （NFR） 指定可用于测试系统功能有效性的质量标准。
SysML 预先定义 NNF 的以下构造型专用化：
[性能要求]
[接口要求]
[设计介绍]
[物理要求]
需求图（要求）：SysML 要求图是一个静态结构图，显示需求 （[要求]） 构造、满足（[满足] 依赖项）的模型元素以及验证（[验证] 依赖项）它们的测试用例之间的关系。
目的
要求图的目的是在模型中同时指定功能性要求和非功能性要求，以便可追溯到满足它们的其他模型元素以及验证它们的测试用例。
【项目中应用】
4.7 fault tolerance（容错）
【定义】
The capability of a system to continue normal operation despite thepresence of (hardware or software) faults.Fault tolerance may be stated as a quality requirement.
【链接】
|
https://www.sciencedirect.com/topics/computer-science/fault-tolerance |
【原文】
Fault tolerance is a quality of a computer system that gracefully handles the failure of component hardware or software. A system can be described as fault tolerant if it continues to operate satisfactorily in the presence of one or more system failure conditions.
Fault tolerance can be achieved by anticipating failures and incorporating preventative measures in the system design. Below are examples of techniques to mitigate and tolerate failure in a computer system.
How to design for fault tolerance
- Power failure - Have the computer or network device running on a UPS (uninterruptible power supply). In the event of a power outage, make sure the UPS can notify an administrator and properly turn off the computer after a few minutes if power is not restored.
- Power surge - If no UPS connects to the computer or the UPS does not provide surge protection, connected devices are not protected. We recommend a surge protector to help protect in the event of a power surge.
- Data loss - Run backups daily or at least monthly on the computer if important information is stored on it. Create a mirror of the data on an alternate location.
- Device or computer failure - Have a second device, computer, or computer components available in the event of failure to prevent a long down time.
- Unauthorized access - If connected to a network, set up a firewall.
- Frequently check for updates - Make sure the operating system and any running programs have the latest updates.
- Lock device or password protect computer - When not in use lock the computer and store the computer or network device in a secure area.
- Overload - Setup an alternate computer or network device to use as an alternative access point or can share the load either through a load balancing or round robin setup.
- Virus - Make sure the computer has updated virus definitions.
【翻译】
容错是计算机系统的一种质量，可以很好地处理组件硬件或软件的故障。如果一个系统在一个或多个系统故障情况下继续令人满意地运行，则该系统可以描述为容错的。
可以通过预测故障并将预防措施纳入系统设计来实现容错能力。以下是缓解和容忍计算机系统故障的技术示例。
如何设计容错能力
- 电源故障-使计算机或网络设备在UPS（不间断电源）上运行。如果断电，请确保UPS可以通知管理员，并且如果无法恢复供电，请在几分钟后正确关闭计算机。
- 电涌-如果没有UPS连接到计算机或UPS不提供电涌保护，则连接的设备不受保护。我们建议使用电涌保护器，以在电涌时帮助保护。
- 数据丢失-如果计算机上存储了重要信息，则每天或至少每月在计算机上运行一次备份。在备用位置上创建数据的镜像。
- 设备或计算机故障-如果发生故障，请提供第二个设备，计算机或计算机组件，以防止长时间停机。
- 未经授权的访问-如果连接到网络，请设置防火墙。
- 经常检查更新-确保操作系统和任何正在运行的程序都具有最新更新。
- 锁定设备或密码保护计算机-不用时，锁定计算机并将计算机或网络设备存储在安全区域。
- 过载-设置备用计算机或网络设备以用作备用访问点，或者可以通过负载平衡或轮询设置来共享负载。
- 病毒-确保计算机已更新病毒定义。
4.8 action sequence(操作序列)
【定义】
An action sequence is a very short story that focuses almost entirely on action.
【链接】
|
https://www.sciencedirect.com/topics/computer-science/action-sequence |
|
https://mrhudyma.com/la7/writing/action-sequence/ |
|
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3854489/ |
【原文】
Step One: Identify the Problem
Most action stories are based on the following problems. Choose one:
The Chase: Someone or something is chasing the protagonist.
The Escape: The protagonist is trapped and tries to escape.
The Showdown: The main character must battle or stand up to the antagonist.
The Attack: Someone or something attacks the main character.
The Impossible Mission: The main character has to overcome a set of ridiculous obstacles.
Step Two: Exposition
The exposition in an action sequence is very short. You only need to provide enough detail for the coming action to make sense.
Use the following questions to help plan your exposition:
Who or what is the protagonist?
Who or what is the antagonist? Depending on your story, you may choose to wait until The Reveal to introduce your antagonist, rather than doing so in the exposition.
Where does the action take place?
Step Three: The Reveal
In order to make your action sequence as exciting as possible, it is important to use suspense to slowly reveal the antagonist. The chart below is an example of how to use sensory details to create suspense by increasing stress.
Step Four: Brainstorm Problems
Think of all the problems your protagonist could encounter in trying to overcome the antagonist. Use a continuum to organize them from minor to major problems.Action Problems
Step Five: Link Problems with Outcomes
Choose 5 problems from your brainstorm that go well together. Organize them in a list from most minor to most major. Beside each problem create a logical outcome that also leads into the next problem.
stumble – animal gets closer
trip on a branch – hurt your ankle and run slower
animal jumps on you – you dive and the animal falls off
animal bites your leg – you kick the animal off and run
animal knocks you down – you grab a stick and stab it in the eye so it runs away
Step Six: Put it all Together
Take your plan and all your ideas and use them to write an amazing action sequence.
【翻译】
第一步：识别问题
大多数动作故事都基于以下问题。选择一个：
大通： 某人或某事在追逐主角。
逃生：主角被困住了，试图逃跑。
摊牌：主角必须战斗或对抗对手。
攻击：某人或某样东西攻击主角。
不可能的任务：主角必须克服一系列荒谬的障碍。
第二步：展览
动作序列中的阐述很短。你只需要提供足够的细节，以便未来的行动有意义。
使用以下问题来帮助规划您的阐述：
主角是谁或什么？
对手是谁或什么？根据您的故事，你可以选择等到《揭秘》来介绍你的对手，而不是在博览会上这样做。
操作在哪里进行？
第三步：揭示
为了使你的动作序列尽可能令人兴奋，重要的是使用悬念慢慢揭示对手。下图是如何使用感官细节通过增加压力来制造悬念的示例。
第四步：集思广益问题
想想你的主角在试图克服对手时可能遇到的所有问题。 使用连续体来组织它们从次要问题到重大问题。操作问题
第五步：将问题与结果联系起来
从头脑风暴中选择 5 个共同好的问题。在从最次要到最专业的列表中组织它们。除了每个问题，还会创建一个逻辑结果，这也会导致下一个问题。
绊倒 = 动物越来越近
绊倒树枝 – 伤了脚踝， 跑得慢
动物跳到你 - 你潜水和动物脱落
动物咬你的腿 - 你踢动物， 跑
动物把你打倒了 — — 你抓住一根棍子， 刺在眼睛里， 这样它就跑开
第六步：把所有部分放在一起
把你的计划和你所有的想法，并使用它们来写一个惊人的动作序列。
4.9 Non-functional requirement(非功能性需求 )
【定义】
A quality requirement or a constraint
质量要求或约束
【链接】
|
https://www.guru99.com/non-functional-requirement-type-example.html |
|
https://www.softwaretestinghelp.com/functional-and-non-functional-requirements/ |
【原文】
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 >加载。非功能性需求的描述与功能要求一样重要。
【项目中应用】
4.10 Performance requirement(性能要求)
【定义】
A requirement describing a performance characteristic
描述性能特征的要求
【链接】
|
http://www.1202performance.com/atricles/how-to-write-performance-requirements-with-example/ |
|
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.
【翻译】
在确定和量化性能要求时，确定特定要求背后的原因非常重要。这是一般容量规划过程的一部分。用户可能基于与程序员的假设不匹配的程序逻辑的假设来陈述需求。
至少，一组性能要求应记录以下内容：
每种不同类型的用户-计算机交互，以及大多数时间的定义，在大多数时间中，都体验到最令人满意的响应时间。响应时间从用户执行"Go"操作的时间开始测量，直到用户从计算机收到足够的反馈以继续任务。这是用户的主观等待时间。直到第一个写入语句，它才从条目到子例程。如果用户拒绝对响应时间感兴趣，并且仅指示结果感兴趣，您可以询问"当前独立执行时间估计的十倍"是否可以接受。如果答案为"是"，您可以继续讨论吞吐量。否则，您可以在用户全神贯注下继续讨论响应时间。
其余时间最低可接受的响应时间。较长的响应时间可能会导致用户认为系统已关闭。还需要指定其余时间;例如，一天的峰值分钟，1% 的交互。在一天中的特定时间，响应时间的降级可能更昂贵或更痛苦。
所需的典型吞吐量和发生时间。这不是一个偶然的考虑。例如，一个程序的要求可能是它每天运行两次：上午 10：00 .m 和下午 3：15 .m。如果这是一个 CPU 限制程序，运行 15 分钟，并计划在多用户系统上运行，则要进行一些协商。
最大吞吐量周期的大小和时间。
预期请求的组合以及组合如何随时间而变化。
每个计算机的用户数和用户总数（如果这是多用户应用程序）。此描述应包括这些用户登录和注销的时间，以及他们假定的击键率、已完成的请求和思考时间。您可能需要调查思考时间是否与前面和下面的请求有系统地变化。
用户对工作负载将运行的计算机所做的任何假设。如果用户有特定的现有计算机，请确保您很早就知道这一点。同样，如果用户假设特定类型、大小、成本、位置、互连或任何其他变量将限制您满足上述要求的能力，则该假设也成为需求的一部分。在开发、测试或首次安装程序的系统上，可能不会评估满意度。
5 读书心得
通过对《需求工程》的阅读，我对软件开发过程中的非技术因素产生的问题有了进一步的理解。需求工程作为软件工程生命周期的起点是软件开发后继阶段的基础。软件需求是软件开发的最终目的，也是项目开发成功与失败的重要因素。当软件的需求分析错误时，该项目的结果肯定是失败的，需求错误可以在开发过程中被及时发现并修复，这样项目的损失也就不会太大。
当我们明白了正确需求的重要性，还要注意一点就是把握软件在开发过程中应该有的功能性和非功能性需求。在软件开发的初期，我们要对项目进行需求分析并撰写需求规格说明书，这在一定程度上给我们一个去探究软件本身应该具备的功能性意义的机会。如果采用了相对合理的需求分析模型，我们就能够快速地开发出系统的初始原型，对于后续开发有很好的帮助，能够准确地定位产品地生命周期，从而使开发过程不至于偏离方向、减少开发过程中走的弯路。
对于用户需求，我们可以通过多次分析，最终确定一个符合用户地需求分析书。在进行需求分析时，分析员应该与目标用户有较深的交流探讨。需求分析不可能只通过一方就能确定。
通过对《需求工程》的学习以及老师的培养，学会了如何去获取需求，如何建模，如何与小组协作分工，共同完成建模。这门课程教会了我们在如何开展开发实际项目的前期工作，如何完整的分析一个系统。
6 小组项目发展建议
对于小组的项目，前期的需求分析并不是很完善，后面在老师的指导下，我们小组的需求分析也逐渐地完善起来，但是还是需要再进一步地深入分析，利用所学的知识，更加准确地去获取项目的需求，建立更加完善的模型。
由于市场上驾校培训系统十分多，大家的水平也是鱼龙混杂，想要在市场上立足就需要有创新，我们应该开创新的商业模式、吸引投资、发展高端用户获取稳定的项目资金。