作业A002-185-2502-李林 课程名称 软件需求分析与建模 班级 18软件工程5班 教导教师 董瑞生 李林 1814080902502 日期 2020.12.15
目录
作业内容
- 目录
- 1、Excel搜索结合项目主题描述
-
- 1.1第一次查词
-
- 1.1.1 判定表(Decision table)
- 1.1.2指导委员会(Steering committee)
- 1.1.3类(Class model)
- 1.1.4上下文模型(Context model)
- 1.1.5操作顺序(Action sequence)
- 1.1.6数据流图(dataflow diagram)
- 1.1.7主动类(Active class)
- 1.1.8构件图(Component diadram)
- 1.1.9复合聚合(Composite aggregation)
- 1.1.10具体类(concrete class)
- 1.1.11基本类型(primitive type)
- 1.1.12关联类(association class)
- 1.1.13类图(class diagram)
- 1.1.14非功能需求( Non-functional requirement)
- 1.1.15需求分析(Requirements analysis)
- 1.1.16二元关联(binary association)
- 1.1.17系统边界(system boundary)
- 第二次查词
-
- 1.2.1系统上下文(System context)
- 1.2.2功能要求(functional requirement)
- 1.2.3时序图(Sequence diagram)
- 1.2.4结构化分析(Structured Analysis)
- 1.2.5行为特征(behavioral feature)
- 1.2.6通信联系(communication association)
- 1.2.7目标模型(Goal model)
- 1.2.8容错(fault tolerance)
- 1.2.9多重继承(mutiple inheritance)
- 1.2.10监护条件(guard condition)
- 1.2.11状态图(statechart diagram)
- 1.2.12需求启发(Requirements Elicitation)
- 1.2.13统一塑模语言(Unified modeling language)
- 1.2.14需求确认(Requirements Validation)
- 1.2.15业务交流(Business Events)
- 第三次查字作业
-
- 1.3.1静态结构(Static Structure)
- 1.3.2需求基线(requirements baseline)
- 1.3.3.软件需求规范(Requirements specification)
- 1.3.4用例图( Use case diagram)
- 1.3.5模型的行为侧重点(behavioral model aspect)
- 1.3.6系统架构(System Architecture)
- 1.3.7通信图(collaboration diagram)
- 1.3.8动作(action)
- 1.3.9行为模型(Behavior model)
- 1.3.10内部转换(internal transition)
- 1.3.11对象生命线(object lifeline)
- 1.3.12多重分类(multiple classification)
- 1.3.13链端点(link end)
- 1.3.14状态图(statechart diagram)
- 1.3.15状态机模型(State Machine Models)
- 第四次查词作业
-
- 1.4.1互动流程图(Interactive Flow Diagram)
- 1.4.2平台独立模型(Platform Independent Models)
- 1.4.3业务交流(Business Events)
- 1.4.4存储库模式(The Repository Pattern)
- 1.4.5异步动作(asynchronous action)
- 1.4.6序列图(sequence diagram)
- 1.4.7建模语言(Modeling language)
- 1.4.8性能要求(Performance requirement)
- 1.4.9需求工程(Requirements Engineering)
- 1.4.10状态机(State machine)
- 1.4.11抽象(abstraction)
- 1.4.12动作序列(action sequence)
- 1.4.13需求文档(Requirements document)
- 1.4.14互动模型(Interaction Models)
- 1.4.15重用层级(Reuse Levels)
- 1.4.16激活(activation)
- 1.4.17序列模型(Sequence Models)
- 1.4.18实际参数(actual parameter)
- 1.4.19异步操作(asynchronous action)
- 1.4.20二元关联(binary association)
- 1.4.21持久对象(persistent object)
- 1.4.22基本类型(Primitive type)
- 1.4.23系统边界(System boundary)
- 2.读书笔记
-
- 2.1读书笔记一
- 2.2读书笔记二
- 2.3读书笔记三
- 3.项目前景
- 4.建议影院管理体系的发展
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 whe 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 “label” 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. 静态数据结构的一个主要优点是,在固定内存分配的情况下,在添加新项或删除现有项时,无需控制或监督即可防止潜在的上溢或下溢问题。这使静态数据结构更易于编程,但以内存消