A002-185-2532
作者：互联网
计算机科学与工程学院期末报告
| 课程名称 | 软件需求分析与建模 | 班级 | 18软工5班 |
| ||||
| 作业名称 | 个人作业 | 教导教师 | 董瑞生 |
| ||||
| 姓名 | 蔡浩凯 | 学号 | 1814080902532 | 日期 | 2020年12月20日 |
| ||
|
|
|
|
|
| ||||
1、 Requirements baseline（需求基线） 5
2、 多重继承（Multiple Inheritance） 6
3、协作图(collaboration diagram) 7
12、Dynamic Classification（动态分类） 21
13、multiple classification（多重分类） 22
15、interaction diagram(交互图) 24
16、Structured Analysis（结构化分析） 28
20、Containment Hierarchy（容器分层结构） 34
21、internal transition（内部转移） 37
23、parameterized element(参数化元素) 45
24、boolean expression（布尔表达式） 47
32、Internal block diagram（内部模块图） 64
38、development process（开发流程） 87
39、binary association（二元关联关系） 88
一、Excel查找档与项目结合
A requirements baseline is a snapshot in time that represents an agreed-upon, reviewed, and approved set of requirements that have been committed to a specific product release.
That “release” could be a complete delivered product or any interim development increment of the product. When stakeholders “sign off” on requirements, what they’re really doing is agreeing and committing to a specific requirements baseline (whether they think of it in those terms or not).
Once the project team establishes a requirements baseline, the team should follow a pragmatic change control process to make good business and technical decisions about adding newly-requested functionality and altering or deleting existing requirements.
需求基准是及时的快照，代表已承诺，已审核和已批准的特定产品版本的一组需求。
“发布”可以是完整的交付产品，也可以是产品的任何中期开发增量。当利益相关者“拒绝”需求时，他们真正要做的就是同意并致力于特定的需求基准（无论他们是否以这些术语考虑）。
一旦项目团队建立了需求基准，团队就应遵循务实的变更控制流程，以就添加新请求的功能以及更改或删除现有需求做出良好的业务和技术决策。
变更控制过程与扼杀变更无关。这是为决策者提供信息，使他们能够及时，适当地做出决定，以修改计划的功能。计划的功能是基准。
通常，还给基线指定了唯一的名称，以便所有项目参与者都可以明确地引用它。良好的配置管理实践使团队可以准确地重建任何先前的基准及其所有组件。
我们项目的需求基线就是教师能够精确找到学生并查看学生或录入学生的成绩，学生也能够查看自己的成绩。
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编译器提供了一些规则来确定特定类使用哪种默认方法。
| 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 |
项目中有经常用到多重继承，例如一个教师可以查询多个学生的成绩，一个学生可以查询多门学科的成绩等，多重继承提供了更便捷灵活的多种可能。
3、协作图(collaboration diagram)
3.1、原文
The collaboration diagram is used to show the relationship between the objects in a system. Both the sequence and the collaboration diagrams represent the same information but differently. Instead of showing the flow of messages, it depicts the architecture of the object residing in the system as it is based on object-oriented programming. An object consists of several features. Multiple objects present in the system are connected to each other. The collaboration diagram, which is also known as a communication diagram, is used to portray the object's architecture in the system.
协作图用于显示系统中对象之间的关系。序列图和协作图表示相同的信息，但不同。它没有显示消息流，而是描述了驻留在系统中的对象的体系结构，因为它是基于面向对象编程的。一个物体由几个特征组成。系统中存在的多个对象相互连接。协作图，也称为通信图，用于描述系统中对象的体系结构。
3.2、链接
3.3、项目应用
这张图本项目没有参与绘制，不过分析可知，此图和时序图表示的信息很相似，所以大概就可以用时序图来替换这个协作图，而这个协作图同样地可以作为参考，下次再进行绘图时可以试着画协作图而省略时序图。
4、 active object（活动对象）
4.1、原文
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中，主动类和对象的区别在于边框比被动对象厚。
4.2、链接
| href="https://community.cadence.com/cadence_technology_forums/f/pcb-design/36981/active-classes-and-sub-classes" https://community.cadence.com/cadence_technology_forums/f/pcb-design/36981/active-classes-and-sub-classes |
4.3、项目应用
主动对象模式是活动图的一个实例，并且根据他常用于解决多线程问题中，基于本项目是学生成绩管理系统，所以基本不存在高并发，多线程等问题，所以该图对本项目作用不大，在后面项目改进过程中可能会运用到。
5、时序图（Sequence Diagram）
5.1、原文
A diagram that shows object interactions arranged in time sequence. In particular, it shows the objects participating in the interaction and the sequence of messages exchanged. Unlike a collaboration diagram, a sequence diagram includes time sequences but does not include object relationships. A sequence diagram can exist in a generic form (describes all possible scenarios) and in an instance form (describes one actual scenario). Sequence diagrams and collaboration diagrams express similar information, but show it in different ways. See: collaboration diagram.
5.2、链接
| https://www.smartdraw.com/sequence-diagram/ |
| https://www.geeksforgeeks.org/unified-modeling-language-uml-sequence-diagrams/ |
5.3、项目应用
我在做本项目的时序图时，会涉及7种元素：角色(Actor)、对象(Object)、生命线、控制焦点、消息、自关联消息、组合片段。其中前6种是比较常用和重要的元素，剩余的一种组合片段元素不是很常用，但是比较复杂。所以并没有加入组合片段。
6、dataflow diagram（数据流图）
6.1、原文
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：
系统逻辑信息流
物理系统建设要求的确定
符号的简单性
建立手动和自动系统要求
6.2、链接
| https://www.smartdraw.com/data-flow-diagram/ |
| https://www.visual-paradigm.com/tutorials/data-flow-diagram-dfd.jsp |
| https://123projectlab.com/data-flow-diagram-symbols-and-examples/ |
6.3、项目应用
本项目没使用该UML图，在后续的项目改进中，会引入这个UML图。
7、System boundary（系统边界）
7.1、原文
A System Boundary element is a non-UML element used to define conceptual boundaries. We can use System Boundaries to help group logically related elements (from a visual perspective, not as part of the UML model).
We can also define a Use Case as the classifier of a System Boundary element, to link the elements enclosed in the System Boundary (such as parts of an Activity diagram) to their representation in a logical Use Case.
The element properties for a System Boundary element comprise the name, the border style, and the number of horizontal or vertical swim lanes. You can also change the overall shape of the System Boundary.
A System Boundary element can be marked as 'Selectable', using the element's context menu. When the element is not selectable, you can click on the other elements within the System Boundary space without activating or selecting the System Boundary itself.
系统边界元素是用于定义概念边界的非UML元素。我们可以使用系统边界来帮助对逻辑相关的元素进行分组（从可视化的角度，而不是作为UML模型的一部分）。
我们还可以将用例定义为系统边界元素的分类器，将封闭在系统边界中的元素（例如活动图的一部分）与其在逻辑用例中的表示联系起来。
系统边界元素的元素属性包括名称、边界样式和水平或垂直泳道的数量。也可以修改系统边界的整体形状。
系统边界元素可以使用元素的上下文菜单标记为“可选”。当图元不可选择时，可以单击系统边界空间内的其他图元，而无需激活或选择系统边界本身。
7.2、链接
| 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 |
7.3、项目应用
系统边界是系统与环境的分界面。用以区分系统与环境(或系统)的本质不同和系统所包含的要素的界限。边界有物理边界与非物理边界两种。如国家在地理上分界、生物系统在细胞膜上分界，均属物理边界;人们在工作中划分职责范围，属非物理边界。边界对系统与环境来说具有一定的隔离作用，这不仅对系统的形成与保护有重要意义，而且使各种系统共处于同一环境中也不丧失其独立性。
8、Action sequence（操作顺序）
8.1、原文
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”后缀。
8.2、链接
| https://www.sciencedirect.com/topics/computer-science/action-sequence |
| http://driftwoodgaming.com/rpg-maker-mv/action-sequences/basic-attack/ |
8.3、项目应用
操作序列就是操作优先级，也是操作的执行顺序。本项目的操作序列是教师先对学生成绩进行录入，学生才可以查询自己的成绩。
9、deployment diagram(部署图)
9.1、原文
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
lWhat existing systems will the newly added system need to interact or integrate with?
lHow robust does system need to be (e.g., redundant hardware in case of a system failure)?
lWhat and who will connect to or interact with system, and how will they do it
lWhat middleware, including the operating system and communications approaches and protocols, will system use?
lWhat hardware and software will users directly interact with (PCs, network computers, browsers, etc.)?
lHow will you monitor the system once deployed?
lHow secure does the system needs to be (needs a firewall, physically secure hardware, etc.)?
Purpose of Deployment Diagrams
lThey show the structure of the run-time system
lThey capture the hardware that will be used to implement the system and the links between different items of hardware.
lThey model physical hardware elements and the communication paths between them
lThey can be used to plan the architecture of a system.
lThey 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它们对于记录软件组件或节点的部署也很有用
部署图一览
部署图对于可视化，指定和记录嵌入式，客户端/服务器和分布式系统以及通过正向和反向工程管理可执行系统非常重要。
部署图只是一种特殊的类图，它专注于系统的节点。在图形上，部署图是顶点和弧的集合。
9.2、链接
| href="https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-deployment-diagram/" https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-deployment-diagram/ |
| https://online.visual-paradigm.com/cn/diagrams/tutorials/deployment-diagram-tutorial/ |
9.3、项目应用
因为本项目还没有最终落实到开发部署服务器环节，所以部署图也就没有实战环节了，所以我更多的是去学习了其相关的概念。
部署图的元素有：
1、结点（Node）
2、结点实例（Node Instance）
3、结点类型（Node Stereotypes）
4、物件（Artifact）
5、连接（Association）
6、结点容器（Node as Container）
10、composite state（组合状态）
10.1、原文
Composite States are composed within the StateMachine diagram by expanding a State element, adding Regions if applicable, and dragging further State elements, related elements and connectors within its boundaries. The internal State elements are then referred to as Substates.
(You can also define a State element, as with many other types of element, as a composite element; this then has a hyperlink to a child diagram that can be another StateMachine diagram or other type of diagram elsewhere in the model.)
Composite States can be orthogonal, if Regions are created. If a Composite State is orthogonal, its entry denotes that a single Substate is concurrently active in each Region. The hierarchical nesting of Composite States, coupled with Region use, generates a situation of multiple States concurrently active; this situation is referred to as the active State configuration.
复合状态是在状态机图中通过展开状态元素、添加区域（如果适用）以及在其边界内拖动更多的状态元素、相关元素和连接器来组成的。内部状态元素被称为子状态。复合如果创建了区域，则状态可以是正交的。如果一个复合状态是正交的，它的条目表示在每个区域中有一个单独的子状态同时处于活动状态。复合状态的分层嵌套，再加上区域使用，会产生多个状态同时处于活动状态的情况；这种情况称为活动状态配置。
10.2、链接
| href="https://www.sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/compositestate.html" https://www.sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/compositestate.html |
| https://online.visual-paradigm.com/diagrams/templates/state-machine-diagram/composite-state/ |
10.3、项目应用
本项目几乎每一处图都用到了组合的形式，因为这能很方便的显示出系统的架构以及各个部分运用的关联关系。
11、statechart diagram（状态图）
11.1、原文
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中，可以使用行为状态机图对系统的行为进行建模。
11.2、链接
| https://www.tutorialspoint.com/uml/uml_statechart_diagram.htm |
|
|
|
|
|
| |
| https://www.geeksforgeeks.org/unified-modeling-language-uml-state-diagrams/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
11.3、项目应用
状态图是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应。通常我们创建一个UML状态图是为了以下的研究目的:研究类、角色、子系统、或组件的复杂行为。就比如本项目中，教师与学生的复制关系，一个教师可以教多个学生，一个学生可以给多个老师教。
12、Dynamic Classification（动态分类）
12.1、原文
Dynamic classification also known as “dynamic typing” deals with the capability of changing the “object classification”. The object may vary its classification in its existence. For example, the below diagram shows the dynamic classification of person's job. The “Bob” object changes its subtypes to instance of “Manager”, “Engineer”, “Salesman”. Even though the object changes its subtypes, it still belongs to “Person” type only. In general, dynamic classification permits an object to take different object types from time to time.
Life cycle of Object
When the object class type is known, the object is categorized and instantiated to that particular type. When the object becomes obsolete in the explicit type, then the object is declassified and deleted from that particular type.
In Programming Language
In computer programming languages, the dynamic classification plays an important role. Describing the object classification changes is a significant feature of object oriented analysis. Some programming languages support limited degree of dynamic classification while other programming languages do not provide the direct support. To implement the dynamic classification in programs, create a new object for the class whenever the object changes its class. Then copy the previous object characteristics into the new object and then delete the old object.
12.2、链接
|
|
|
|
|
|
|
|
|
|
|
|
| |
| https://www.chegg.com/homework-help/definitions/dynamic-classification-3 |
|
|
|
|
|
|
|
|
|
|
|
|
| https://www.onlinelibrary.wiley.com/doi/abs/10.1002/minf.202000173 |
|
|
|
|
|
|
|
|
|
|
|
|
12.3、项目应用
这个概念我还是第一次见到，不过经过学习，我觉得可以将这个知识运用到我们的用户分类上，例如原来项目只有用户这一类，通过用户类里的role这个属性来区分是普通用户还是商户还是管理员，这显然是欠妥当的，所以我们可以采用动态分类来解决，即：首先将这三个角色的公共特征抽出取来，比如姓名、手机号、密码等，作为一个People基类，然后再用三个类来继承这一个基类。这就体现了动态分类。
13、multiple classification（多重分类）
13.1、原文
Multilabel classification: classification task labelling each sample with x labels from n_classes possible classes, where x can be 0 to n_classes inclusive. This can be thought of as predicting properties of a sample that are not mutually exclusive. Formally, a binary output is assigned to each class, for every sample. Positive classes are indicated with 1 and negative classes with 0 or -1. It is thus comparable to running n_classes binary classification tasks, for example with sklearn.multioutput.MultiOutputClassifier. This approach treats each label independently whereas multilabel classifiers may treat the multiple classes simultaneously, accounting for correlated behavior among them.
For example, prediction of the topics relevant to a text document or video. The document or video may be about one of ‘religion’, ‘politics’, ‘finance’ or ‘education’, several of the topic classes or all of the topic classes.
13.2、链接
| https://en.wikipedia.org/wiki/Multiclass_classification |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
13.3、项目应用
本项目由于还没有到那个复杂的程度，所以还没有进入多级分类这个概念，后续对项目改进后可能会将其引入项目。
14、object lifeline（对象生命线）
14.1、原文
Used in a sequence diagram, an object lifeline represents the existence of an object at a particular time. If the object is created or destroyed during the time period the diagram represents, then the lifeline stops or starts at the appropriate point.
在序列图中，对象生命线表示对象在特定时间的存在。如果对象是在图表所表示的时间段内创建或销毁的，则生命线将在适当的点停止或启动。
14.2、链接
| https://support.microsoft.com/en-us/office/object-lifeline-shape-2cd8ab65-36f6-46f1-ac12-3aeb1bd5534b |
|
|
|
|
|
|
|
|
|
|
| https://creately.com/diagram-type/objects/sequence-diagram |
|
|
|
|
|
|
|
|
|
|
| https://sparxsystems.com/resources/tutorials/uml2/sequence-diagram.html |
|
|
|
|
|
|
|
|
|
|
14.3、项目应用
对象生命线是EA的一个线性工具，用来连接指向生命周期的下一步，本项目对其也进行了引用。
15、interaction diagram(交互图)
15.1、原文
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中进行补救，已经做了很多事情。
15.2、链接
|
|
|
|
|
|
|
|
| |
| https://www.sciencedirect.com/topics/computer-science/interaction-diagram |
|
|
|
|
|
|
|
|
| https://www.tutorialspoint.com/uml/uml_interaction_diagram.htm |
|
|
|
|
|
|
|
|
15.3、项目应用
当您要查看单个用例中多个对象的行为时，应使用交互图。它们擅长显示对象之间的协作，而不能精确定义行为。项目中也对其进行了引用，比如教师对多个学生成绩进行录入时，就使用了交互图。
16、Structured Analysis（结构化分析）
16.1、原文
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.
软件开发领域的术语结构化分析描述了计算机应用程序设计中使用的一系列技术。这些技术有助于以更人性化的方式解释计算机应用程序中所需的步骤。彻底的结构化分析和设计方法的结果通常描述了计算机应用程序的物理层和逻辑层。软件工程是一个复杂的过程，它需要关于软件应用程序如何运行的细节的复杂细节。软件工程的早期先驱们认识到，这种复杂性需要一种形式化的方法，这种方法不仅可以记录系统，而且可以用一般公众可以理解的术语来解释过程。结构化分析是用来记录这种复杂性的过程。
结构化分析和设计在应用程序体系结构中分为四个主要领域。这些是数据流、数据模型、结构图和状态模型。所有这些领域通常都是以一种方式表示的，即从摘要级别开始，然后进入详细的解释级别
16.2、链接
| https://www.geeksforgeeks.org/structured-analysis-and-structured-design-sa-sd/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| https://www.tutorialspoint.com/system_analysis_and_design/system_analysis_and_design_structured.htm |
|
|
|
|
|
|
|
|
|
|
|
16.3、项目应用
结构化分析(Structured Analysis，简称SA)是软件工程中的一种方法，结构化分析和结构化设计可以分析商业的需求，再转换为规格文件，最后再产生电脑软件、硬件配置及相关的手册及程序。结构化分析及设计技术是系统分析的基础，这门课是主要是针对需求分析而开的，对于系统分析并没有那么重点，所以，该知识只是做了个了解，并没有过多在项目中使用。
17、Generalization（一般化）
17.1、原文
A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element may be used where the more general element is allowed. See: inheritance.
也称泛化，可以理解为更一般的元素和更具体的元素之间的分类关系。更具体的元素与更一般的元素完全一致，并包含附加信息。如果允许使用更一般的元素，则可以使用更具体元素的实例。同时，根据我自身的编程经验，我可以从代码层面理解为是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java中此类关系通过关键字extends明确标识，在设计时一般没有争议性。
17.2、链接
| href="../Documents/WeChat Files/wxid_7q12lj1f8lr522/FileStorage/File/2020-10/工作簿1.xlsx" https://www.sciencedirect.com/topics/computer-science/requirement-engineering |
|
|
|
|
|
|
|
|
|
| https://www.techopedia.com/definition/21697/requirements-engineering |
|
|
|
|
|
|
|
|
|
| https://www.geeksforgeeks.org/software-engineering-requirements-engineering-process/ |
|
|
|
|
|
|
|
|
|
17.3、项目应用
这个一般化很类似于继承这个概念，所以运用起来就跟继承差不多，此处就不展开进行了。
18、actual parameter （实际参数）
18.1、原文
Formal parameter — the identifier used in a method to stand for the value that is passed into the method by a caller.
lFor example, amount is a formal parameter of processDeposit
actual parameter — the actual value that is passed into the method by a caller.
lFor example, the 200 used when processDeposit is called is an actual parameter.
lactual parameters are often called arguments
实际参数-调用方传递给方法的实际值。
例如， 当被进程调用的200 是实际参数。
实际参数通常称为参数
18.2、链接
https://chortle.ccsu.edu/java5/Notes/chap34A/ch34A_3.html
https://java4school.com/actual-and-formal-parameters
https://en.wikipedia.org/wiki/Parameter_(computer_programming)
18.3、项目应用
参数这个对于计算机专业应该是很耳熟的一个词了吧，在一个软件中，我们要定义很多很多的参数，使用这些参数来帮助我们完成一些功能的实现，比如本项目的教师，学生都是我们定义的参数，用来实现该系统。
19、Use case diagram（用例图）
19.1、原文
What is a use case diagram?
In the Unified Modeling Language (UML), a use case diagram can summarize the details of your system's users (also known as actors) and their interactions with the system. To build one, you'll use a set of specialized symbols and connectors. An effective use case diagram can help your team discuss and represent:
Scenarios in which your system or application interacts with people, organizations, or external systems
Goals that your system or application helps those entities (known as actors) achieve
The scope of your system
When to apply use case diagrams
A use case diagram doesn't go into a lot of detail—for example, don't expect it to model the order in which steps are performed. Instead, a proper use case diagram depicts a high-level overview of the relationship between use cases, actors, and systems. Experts recommend that use case diagrams be used to supplement a more descriptive textual use case.
UML is the modeling toolkit that you can use to build your diagrams. Use cases are represented with a labeled oval shape. Stick figures represent actors in the process, and the actor's participation in the system is modeled with a line between the actor and use case. To depict the system boundary, draw a box around the use case itself.
UML use case diagrams are ideal for:
Representing the goals of system-user interactions
Defining and organizing functional requirements in a system
Specifying the context and requirements of a system
Modeling the basic flow of events in a use case
Diagramming is quick and easy with Lucidchart. Start a free trial today to start creating and collaborating.
19.2、链接
| https://creately.com/blog/diagrams/use-case-diagram-tutorial/ |
19.3、项目应用
用例图主要就是对用户的一种UML图构建，在项目中多处应用。
20、Containment Hierarchy（容器分层结构）
20.1、原文
SysML can be used to model text-based requirements and relate them to other requirements and to other model elements. The following are some of the key requirements modeling concepts.
The SysML requirements modeling capability serves as a bridge between traditional text-based requirements and the modeling environment. The requirements can be imported from a requirements management tool, or text specification, or created directly in the modeling tool.
Each specification is generally captured in a package. The package structure can correspond to a traditional specification tree. Each specification in turn includes a containment hierarchy of the requirements contained within the specification. The browser view in most tools can be used to view the requirements containment hierarchy.
The individual or aggregate requirements can then be related to other requirements in other specifications as well as model elements that represent the design, implementation, or test cases. The requirements relationships include derive, satisfy, verify, refine, trace, and copy. These relationships provide a robust capability for managing requirements and supporting requirements validation and verification so that the design satisfies the requirements.
There are multiple notational representations to enable requirements to be related to other model elements on other diagrams; they include direct notation, compartment notation, and callout notation. The requirement diagram is generally used to represent a containment hierarchy or to represent the relationships for a particular requirement. Tabular notations are also used to efficiently report requirements and their relationships.
20.2、链接
http://www.web-feats.com/classes/javaprog/lessons/swing_gui_intro/containment.htm
https://www.sciencedirect.com/topics/computer-science/containment-hierarchy
http://www.firstobject.com/dn_markhierarchy.htm
20.3、项目应用
这个容器分层结构可以说相当的难以理解，我是这样理解的，拿项目的组织模型来说，由于一层传递是绝对不够用的，所以就可以运用分层结构。
21、internal transition（内部转移）
21.1、原文
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.
Define an Internal Transition
| Step | Action | See also |
| 1 | In the Project Browser, double-click on the StateMachine diagram containing the State element to open it. |
|
| 2 | On the State element, create a Transition connector issuing from and terminating in the element (a 'self Transition'). In the Diagram Toolbox, select the Transition connector, then click and release on the State element. |
|
| 3 | Right-click on the connector and select the 'Properties' option to display the 'Properties' dialog. |
|
| 4 | Select the 'Constraints' tab and define any guard, effect and trigger for the Transition. | |
| 5 | Select the 'General' tab, then select the child tab 'Advanced'. Click on the drop-down arrow in the value field for the kind property and select internal. |
|
| 6 | Click on the OK button. The Transitions display in the same compartment as internal activities (exit/, do/, entry/).
|
|
Notes
To view or edit the properties of the internal Transition, double-click on the entry in the compartment within the State
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
21.2、链接
| https://statecharts.github.io/glossary/local-transition.html |
|
| https://sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/internal_transition.html | |
21.3、项目应用
内部转移即有一些操作在内部进行处理，处理完后直接交给下一个任务，逻辑处理都是在内部的，比如我们项目中教师录入成绩失败后的处理就是直接重新调回录入页面，这就是一个内部转移。
22、Acceptance test（验收测试）
22.1、原文
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
There are several types of this testing.
Few of them are listed below:
#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.
=> Also Read: What is User Acceptance Testing (UAT)?
#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.
什么是验收测试?
一旦系统测试过程测试团队完成签订,整个产品/应用程序交给客户/客户的一些用户,为其可接受性测试即产品/应用程序应该是完美的在会议的关键和主要的业务需求。
此外，端到端业务流的验证与实时场景类似。
类似生产的环境将是用于接受测试的测试环境(通常称为分段、预prod、故障转移、UAT环境)。
这是一种黑盒测试技术，只验证功能，以确保产品满足指定的验收标准(不需要设计/实现知识)。
为什么验收测试?
虽然系统测试已经成功完成，但客户仍要求进行验收测试。
这里进行的测试是重复的，就像它们在系统测试中所包含的一样。
那么，为什么这个测试是由客户进行的呢?
这是因为:
对即将投放市场的产品获得信心。
以确保产品以它必须的方式工作。
确保产品符合当前的市场标准，并与市场上其他同类产品有足够的竞争力。
类型
这种测试有几种类型。
下面列出了其中的少数几种:
1)用户验收测试(UAT)
UAT是评估产品是否为用户工作，是否正确使用。
终端用户经常使用的特定需求主要是为了测试目的而选择的。
这也称为最终用户测试。
这里的术语“用户”表示产品/应用程序所面向的最终用户，因此，从最终用户的角度和他们的观点执行测试。
=>也读:什么是用户验收测试(UAT)?
业务验收测试(BAT)
这是为了评估产品是否满足业务目标和目的。
BAT主要关注业务利益(财务)，由于市场条件的变化/技术的进步，业务利益(财务)是相当具有挑战性的，因此当前的实现可能不得不进行更改，从而导致额外的预算。
即使产品通过了技术要求，也可能因为这些原因而失败。
合同验收测试(CAT)
这是一个合同，它规定一旦产品在预定的期限内上线，就必须执行验收测试，并且它应该通过所有的验收用例。
这里签订的合同称为服务水平协议(SLA)，其中包含了只有在产品服务符合所有要求时才付款的条款，即合同已履行。
有时，合同可能发生在产品发布之前。
无论是哪种方式，合同都应该在测试期间、测试区域、后期遇到的问题的条件、付款等方面进行明确定义。
法规/合规性验收测试(RAT)
这是为了评估产品是否违反了其发布国政府所定义的法规。
这可能是无意的，但会对业务产生负面影响。
通常，开发的产品/应用程序，打算发布在世界各地，必须经过RAT，因为不同的国家/地区有不同的规则和规定，由其管理机构定义。
如果违反任何国家的任何规章制度，则该国家或该国的特定地区将不允许使用该产品，并视为不合格产品。
如果产品被发布，即使存在违规行为，产品的供应商也将承担直接责任。
运行验收测试(OAT)
这是一个非功能测试，用于评估产品的操作准备情况。
主要包括恢复测试、兼容性测试、可维护性测试、技术支持可用性测试、可靠性测试、故障转移测试、本地化测试等。
OAT主要保证产品在投入生产前的稳定性。
# 6)α测试
这是由专门的测试团队(通常称为alpha测试人员)在开发/测试环境中评估产品。
在这里，测试人员的反馈和建议有助于改进产品的使用，并修复某些bug。
在这里，测试以受控的方式进行。
22.2、链接
https://www.agilealliance.org/glossary/acceptance/
https://www.softwaretestinghelp.com/what-is-acceptance-testing/
22.3、项目应用
验收测试，系统开发生命周期方法论的一个阶段，这时相关的用户和／或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。由于本课程主要是针对需求分析，所以还没有进行开发，就没有验收测试。
23、parameterized element(参数化元素)
23.1、原文
A templateable element is an element that can optionally be defined as a template or bound to other templates.
Template class Array and bound class Customers.
Template
Template is a templateable element that contains a template signature.
Collaboration template Visit with two unconstrained class formal parameters.
Bound Element
Bound element is a templateable element that contains bindings to templates that describe how the templateable element is constructed by replacing the formal template parameters with actual parameters.
Package template Service Provider and bound package Scheduler Service.
23.2、链接
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
23.3、项目应用
对于这个知识点本项目中并没有使用到，于是对这个只是点进行了学习，如下：
参数化设计是Revit Building的一个，它分为两个部分:参数化图元和参数化修改引擎。Revit Building中的图元都是以构件的形式出现，这些构件之间的不同，是通过参数的调整反映出来的，参数保存了图元作为数字化建筑构件的所有信息。参数化修改引擎提供的参数更改技术使用户对建筑设计或文档部分作的任何改动都可以自动的在其它相关联的部分反映出来，采用智能建筑构件、视图和注释符号，使每一个构件都通过一个变更传播引擎互相关联。构件的移动、删除和尺寸的改动所引起的参数变化会引起相关构件的参数产生关联的变化，任一视图下所发生的变更都能参数化的、双向的传播到所有视图，以保证所有图纸的一致性，毋须逐一对所有视图进行修改。从而提高了工作效率和工作质量。
24、boolean expression（布尔表达式）
24.1、原文
A Boolean expression is a logical statement that is either TRUE or FALSE. Boolean expressions can compare data of any type as long as both parts of the expression have the same basic data type. You can test data to see if it is equal to, greater than, or less than other data.
A Boolean expression can consist of Boolean data, such as the following:
BOOLEAN values (YES and NO, and their synonyms, ON and OFF, and TRUE and FALSE)
BOOLEAN variables or formulas
Functions that yield BOOLEAN results
BOOLEAN values calculated by comparison operators
For example, assume that your code contains the following Boolean expression.
actual GT 20000
When processing this expression, Oracle OLAP compares each value of the variable actual to the constant 20,000. When the value is greater than 20,000, then the statement is TRUE; when the value is less than or equal to 20,000, then the statement is FALSE.
When you are supplying a Boolean value, you can type either YES, ON, or TRUE for a true value, and NO, OFF, or FALSE for a false value. When the result of a Boolean calculation is produced, the defaults are YES and NO in the language specified by the NLS_LANGUAGE option. The read-only YESSPELL and NOSPELL options record the YES and NO values.
Table 2-9, "Comparison and Logical Operators" shows the comparison and logical operators. Each operator has a priority that determines its order of evaluation. Operators of equal priority are evaluated left to right, unless parentheses change the order of evaluation. However, the evaluation is halted when the truth value is already decided. For example, in the following expression, the TOTAL function is never executed because the first phrase determines that the whole expression is true.
24.2、链接
| https://docs.oracle.com/cd/B12037_01/olap.101/b10339/expression006.htm |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
24.3、项目应用
布尔表达式是对一个行为表示成功与否，成功返回true，错误返回false，在本项目中，有多处引用，比如很多图都是判断框，里面就有是否满足条件，化为代码就是true和false。
25、association class （关联类）
25.1、原文
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.
Contributors: MichaelFeathers, PeterMerel
In UML, an association class is "A modeling 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" (UML 1.1 Semantics, Appendix B: Glossary).
Also found: "association class symbol designates an association that has class-like properties, such as attributes, operations, and other associations".
It follows that, in UML, an AssociationClass is a Class, a tuple. As such it is an unnecessary, redundant feature. --MarcoScheurer
I'm afraid neither of your quotes lead me to your conclusion. An association can have plurality, ergo an AssociationClass can have more than one tuple. That makes it handy and far from redundant. --PeterMerel
I don't think this follows. An association is a tuple which relates classifiers. It defines a set of tuples which relate instances. This is parallels the fact that a class defines a set of instances. So, an instance of an AssociationClass is exactly one link object in the same way that an instance of a class is exactly one object of the class (not counting other associations). Or, should we start to say that an instance of a class is a set of objects?
An association defines a set of tuples which relate instances, sure. The rest is your surmise. Now perhaps there is some point in promoting this surmise, and I'm sure we could engage in some debate about it, but frankly I find this whole thing quite Swiftian. Does your class encapsulate an associative array, hash, dictionary, or whatchamacallit? Then I'll be happy to diagram it as an AssociationClass. You agree that you won't be using an AssociationClass for anything else, so kindly accept that I do and stop arguing about which end of the UML egg to open at breakfast.
As to your comments about AssociationClass as some kind of "bad pattern", we are speaking English here, and English adopts meanings by their use, not by fiat. I call a class that encapsulates an associative array (map/hash/dictionary/whatchamacallit) an AssociationClass. You may happily call it anything else you like. But when I speak of AssociationClass(es) I'm content that you know now what I mean, and that you agree that any other meaning is quite useless. Beyond that, please breakfast at any end of the egg you prefer. --PeterMerel
25.2、链接
| 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 |
|
|
|
|
|
|
|
|
|
25.3、项目应用
发现在设计这个学生成绩管理系统中，使用关联类是十分有必要的，就拿教师与学生来说，我们可以用一个关联类里的一个属性来存储老师教了几个学生，值得注意的是，一个学生不止被一个老师教，所以用关联类来记录非常好。
26、guard condition （监护条件)
26.1、原文
Swift Guard Bouncer
When I first saw the Swift guard statement during Apple’s Platform State of the Union, I couldn’t quite understand why I would ever use it. So what is it? The tl;dr is as follows:
Like an if statement, guard executes statements based on a Boolean value of an expression. Unlike an if statement, guard statements only run if the conditions are not met. You can think of guard more like an Assert, but rather than crashing, you can gracefully exit.
Even after seeing some examples, I only saw it as a confusing way to accomplish what we already could with Optional Binding or with if-else statements alone.
It wasn’t until I started discussing it over this Twitter conversation that I realized there are actually some interesting benefits of using such syntax.
26.2、链接
https://ericcerney.com/swift-guard-statement/
https://thatthinginswift.com/guard-statement-swift/
https://docs.swift.org/swift-book/ReferenceManual/Statements.html
26.3、项目应用
本项目没有使用监护条件该知识点，对于该知识点也只是片面理解，后续会加强对该知识的理解，并引用到自己的项目中。
27、state machine（状态机）
27.1、原文
Definition - What does State Machine mean?
A state machine is a concept used in designing computer programs or digital logic. There are two types of state machines: finite and infinite state machines. The former is comprised of a finite number of states, transitions, and actions that can be modeled with flow graphs, where the path of logic can be detected when conditions are met. The latter is not practically used.
A state machine is any device storing the status of something at a given time. The status changes based on inputs, providing the resulting output for the implemented changes. A finite state machine has finite internal memory. Input symbols are read in a sequence producing an output feature in the form of a user interface.
State machines are represented using state diagrams. The output of a state machine is a function of the input and the current state. State machines play a significant role in areas such as electrical engineering, linguistics, computer science, philosophy, biology, mathematics, and logic. They are best used in the modeling of application behavior, software engineering, design of hardware digital systems, network protocols, compilers, and the study of computation and languages.
Techopedia explains State Machine
The operation of a state machine begins from a start state. On a successful transition it ends up in an accept state. The transition takes place based on the inputs provided. The current state depends on the past state of the system. The number of states formed depends on the available states of memory. A transition is enabled based on certain conditions and indicates a state change. An action describes an activity performed at the given moment. The different types of actions are transition action, input action, entry action, and exit action.
Deterministic automata have exactly one transition in every state for each possible input. In non-deterministic automata, a state input leads to one, many, or no transitions. A state machine with only one state is called a combinatorial state machine and uses only input actions.
The two different groups of state machines are acceptors and transducers. Acceptors produce a binary output, based on whether the input is accepted or rejected by the machine. While processing the input, if the current state is accepting, the input is accepted. Otherwise it is rejected. Languages accepted by state machines are called regular languages. Start states are represented by an arrow pointing on it from anywhere, while accepted states are represented using double circles. Transducers cater output based on a given input, using actions. Moore and Mealy machines are examples of transducers.
Unmodified modeling language state machines are also widely used as they have both the Moore and Mealy machine characteristics within them. They include additional concepts such as orthogonal regions and hierarchically-nested states.
27.2、链接
| https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-state-machine-diagram/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
27.3、项目应用
状态机由状态寄存器和组合逻辑电路构成，能够根据控制信号按照预先设定的状态进行状态转移，是协调相关信号动作、完成特定操作的控制中心。对于状态机这个概念我还不是很熟悉，需要再次加强。本项目中状态机发生事件(Event)后，根据当前状态(Current State)决定执行的动作(Action)，并设置下一个状态(Next State)。
28、active object （活动对象）
28.1、原文
Active Objects is a new ORM (object relational mapping) layer into Atlassian products. Active Objects is implemented as a plugin into Atlassian applications. It enables easier, faster, and more scalable data access and storage than the existing Bandana and PluginSettings APIs.
The goal of the Active Objects plugin is to provide a plugin data storage component that plugins can and should use to persist their private data. Active Objects satisfies these requirements:
| Real database | Instead of using a key/value store to mimic a relational database, Active Objects provides plugin developers with access to a real database. |
| Database independence | Active Objects abstracts all database implementation details. The specific underlying database implementation that Active Objects provides should not have any effect on the plugin's implementation, as each product supports multiple databases. |
| ORM interface | The ORM interface bundled with Active Objects allows plugin developers to avoid many common issues and tedious boilerplate code involved in issuing queries, creating schemas and performing migrations between schema versions. |
| Sandboxing | A plugin can access only the data that belongs to it, not data belonging to other plugins or to the host products. |
| Backup/restore | The product's existing database backup/restore (or export/import) mechanisms take care of backing up the plugin data. Note: Backup/restore is fully integrated with JIRA 5.0, but is not yet integrated with all products. Beware of this detail when developing an Active Objects plugin or using another plugin that uses Active Objects. |
28.2、链接
28.3、项目应用
活动对象的话，本项目主要是有3个对象，分别是学生、教师、管理员三个活动对象。
29、Domain Model（领域模型）
29.1、原文
A domain model is a visual representation of conceptual classes or real - situation objects in a domain [M095, Fowler96]. Domain models have also been called conceptual models (the term used in the first edition of this book), domain object models, and analysis object models.
The UP defines the Domain Model as one of the artifacts that may be created in the Business Modeling discipline. More precisely, the UP Domain Model is a specialization of the UP Business Object Model (BOM) "focusing on explaining 'things' and products important to a business domain" [RUP]. That is, a Domain Model focuses on one domain, such as POS related things. The more broad BOM, not covered in this introductory text and not something I encourage creating (because it can lead to too much up - front modeling), is an expanded, often very large and difficult to create, multi - domain model that covers the entire business and all its sub - domains.
Applying UML notation, a domain model is illustrated with a set of class diagrams in which no operations (method signatures) are defined. It provides a conceptual perspective. lt may show:
domain objects or conceptual classes
associations between conceptual classes
attributes of conceptual classes
Definition: Why Call a Domain Model a "Visual Dictionary"?
Please reflect on Figure for a moment. See how it visualizes and relates words or concepts in the domain. It also shows an abstraction of the conceptual classes, because there are many other things one could communicate about registers, sales, and so forth.
The information it illustrates (using UML notation) could alternatively have been expressed in plain text (in the UP Glossary). But it's easy to understand the terms and especially their relationships in a visual language, since our brains are good at understanding visual elements and line connections.
Therefore, the domain model is a visual dictionary of the noteworthy abstractions, domain vocabulary, and information content of the domain.
Definition; Is a Domain Model a Picture of Software Business Objects?
A UP Domain Model, as shown in Figure, is a visualization of things in a real - situation domain of interest, not of software objects such as Java or C# classes, or software objects with responsibilities. Therefore, the following elements are not suitable in a domain model:
Software artifacts, such as a window or a database, unless the domain being modeled is of software concepts, such as a model of graphical user interfaces.
Responsibilities or methods.
A domain model shows real - situation conceptual classes, not software classes
A domain model does not show software artifacts or classes
Definition: What are Two Traditional Meanings of "Domain Model"?
In the UP and thus this chapter, "Domain Model" is a conceptual perspective of objects in a real situation of the world, not a software perspective. But the term is overloaded; it felso has been used (especially in the Small talk community where I did most of my early 00 development work in the 1980s) to mean "the domain layer of software objects." That is, the layer of software objects below the presentation or UI layer that is composed of domain objects - software objects that represent things in the problem domain space with related "business logic" or "domain logic" methods. For example, a Board software class with a get Square method.
Which definition is correct? Well, all of them! The term has long established uses in different communities to mean different things.
I've seen lots of confusion generated by people using the term in different ways, without explaining which meaning they intend, and without recognizing that others may be using it differently.
In this book, I'll usually write domain layer to indicate the second software - oriented meaning of domain model, as that's quite common.
Definition: What are Conceptual Classes?
The domain model illustrates conceptual classes or vocabulary in the domain. Informally, a conceptual classis an idea, thing, or object. More formally, a conceptual class may be considered in terms of its symbol, intension, and extension [M095].
Symbol - words or images representing a conceptual class.
Intension - the definition of a conceptual class.
Extension - the set of examples to which the conceptual class applies.
For example, consider the conceptual class for the event of a purchase transaction. I may choose to name it by the (English) symbol Sale. The intension of a Salemay state that it "represents the event of a purchase transaction, and has a date and time." The extension of Sale is all the examples of sales; in other words, the set of all sale instances in the universe.
Definition: Are Domain and Data Models the Same Thing?
A domain model is not a data model (which by definition shows persistent data to be stored somewhere), so do not exclude a class simply because the requirements don't indicate any obvious need to remember information about it (a criterion common in data modeling for relational database design, but not relevant to domain modeling) or because the conceptual class has no attributes. For example, it's valid to have attributeless conceptual classes, or conceptual classes that have a purely behavioral role in the domain instead of an information role.
A conceptual class has a symbol, intension, and extension
29.2、链接
| href="https://www.hackernoon.com/making-a-case-for-domain-modeling-17cf47030732" https://www.hackernoon.com/making-a-case-for-domain-modeling-17cf47030732 |
| href="https://www.wisdomjobs.com/e-university/uml-tutorial-175/what-is-a-domain-model-13285.html" https://www.wisdomjobs.com/e-university/uml-tutorial-175/what-is-a-domain-model-13285.html |
29.3、项目应用
领域模型是领域内的概念类或现实世界中对象的可视化表示，又称为概念模型或分析对象模型，它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。
贫血模型是指使用的领域对象中只有setter和getter方法（POJO），所有的业务逻辑都不包含在领域对象中而是放在业务逻辑层。有人将我们这里说的贫血模型进一步划分成失血模型（领域对象完全没有业务逻辑）和贫血模型（领域对象有少量的业务逻辑），我们这里就不对此加以区分了。
充血模型将大多数业务逻辑和持久化放在领域对象中，业务逻辑（业务门面）只是完成对业务逻辑的封装、事务和权限等的处理。下面两张图分别展示了贫血模型和充血模型的分层架构
本项目还没有进行开发，所以还没引入领域模型，但是也就这个模型进行了理解，方便后面开发使用。
30、analysis time （验收时间）
30.1、原文
The Information Technology Laboratory (ITL), one of six research laboratories within the National Institute of Standards and Technology (NIST), is a globally recognized and trusted source of high-quality, independent, and unbiased research and data. ITL’s mission, to cultivate trust in information technology (IT) and metrology, is accomplished using its world-class measurement and testing facilities and encompassing a wide range of areas of computer science, mathematics, statistics, and systems engineering.
This non-regulatory role, along with ITL’s deep technical expertise in all fields of information technology, helps increase trust in IT worldwide.
30.2、链接
https://www.itl.nist.gov/div898/handbook/pmc/section4/pmc4.html
https://www.sciencedirect.com/topics/computer-science/pseudostates
https://searchsoftwarequality.techtarget.com/definition/collaboration-diagram
30.3、项目应用
这个概念之前在软件工程也有学过，主要是对编程后的软件进行测试，测试完成后进行验收，由于需求分析不要求代码实现，所以功能测试这一块并没有使用到。
31、action sequence（操作序列）
31.1、原文
Action Sequence
An action sequence is a very short story that focuses almost entirely on action.
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.
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.
Imagine your story is about being chased by an animal in the woods.
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
31.2、链接
| https://www.sciencedirect.com/topics/computer-science/action-sequence |
31.3、项目应用
每当我们设计一个活动图时，里面往往会有许多许多操作，例如：教师对学生的查询，对学生成绩的录入，学生对自己成绩的查询等。
32、Internal block diagram（内部模块图）
32.1、原文
Internal Block Diagram
The internal block diagram or ibd resembles a traditional system block diagram and shows the connections between parts of a block. The internal block diagram header is depicted as follows:
ibd [block] block name [diagram name]
The frame of an internal block diagram always corresponds to a block, so the model element kind is often elided in the diagram header. The block name is the name of the block that is designated by the frame.
Figure 7.2 shows an example internal block diagram containing some common symbols. The diagram describes part of the internal structure of the Camera and how light flows in and through various intermediate parts to the Optical Assembly.
Sign in to download full-size image
FIGURE 7.2. Example internal block diagram.
The notation used in the internal block diagram to describe the usage of blocks (called parts) and their interconnections is shown in the Appendix, Tables A.6, A.11, and A.12A.6A.11A.12. Internal block diagram notation can also be shown in the structure compartment of a block on a block definition diagram. Figures 7.26 and 7.27 both provide examples of this.
32.2、链接
|
|
| |
| href="https://www.sciencedirect.com/topics/computer-science/internal-block-diagram" https://www.sciencedirect.com/topics/computer-science/internal-block-diagram |
|
|
| http://www.vitechcorp.com/resources/core/onlinehelp/desktop/Views/Internal_Block_Diagram_(IBD).htm |
|
|
32.3、项目应用
内部模块图，一个项目可以分成多个模块，把一些功能相似的根据需要放到同一个模块中，方便进行维护，比如我们项目中就把教师模块，学生模块，管理员模块都从项目中分离出来，方便开发与维护。
33、inheritance （继承）
33.1、原文
What Is an Inheritance?
Inheritance refers to the assets that an individual bequeaths to his or her loved ones after he or she passes away. An inheritance may contain cash, investments such as stocks or bonds, and other assets such as jewelry, automobiles, art, antiques, and real estate.
How an Inheritance Works
The value of an inheritance can range from a few thousand dollars to several million dollars. In most countries, inheritance assets are subject to inheritance taxes, where beneficiaries may find themselves saddled with tax liabilities. The rates of an inheritance tax (sometimes referred to as a "death duty" or "the last twist of the taxman's knife) depend on a host of factors, including a beneficiary's state of residence, the value of the inheritance, and the beneficiary's relationship to the decedent.
33.2、链接
| https://www.dictionary.com/browse/inheritance |
| https://www.investopedia.com/terms/i/inheritance.asp |
| https://www.rottentomatoes.com/m/inheritance_2020 |
33.3、项目应用
继承的话，相信计算机专业的都相当熟悉了，就是有一个大家共有的东西把它抽离出来，然后我们取继承它，拥有它的属性，比如在项目中，教师和学生都是人，都是有一些相同的属性，就可以抽离出人这个类，然后其他类对他进行继承。
34、association end（关联端 ）
34.1、原文
Association End
Association Ends are represented by properties each of which is connected to the type of the End. When a property is an Association End, the value or values are related to the instance or instances at the other End(s) of the Association.
An Association End is the connection between lines depicting an Association and the shape.
The following properties of the association end can be specified: name, association end type, visibility, multiplicity, qualifier, aggregation kind.
Association end properties
Name
The Association End has other name - role. A role indicates a role played by the Class in terms of an Association. The role name is placed at the Association End near the Class playing that role. The role name at the implementation level maps to the reference name of the opposite Class. Roles can have visibility (public, package, protected, and private).
Association End type
Changing the Association End type, changes the target of the Association or in other words the classifier to which the Association is connected.
Qualifier
A qualifier is an attribute or a list of attributes whose values serve to partition the set of instances associated with an instance across an Association. Qualifiers are attributes of an Association. It is represented as a small rectangle attached to the End of an Association path between the final path segment and the symbol of the classifier that it connects to. The qualifier rectangle is part of the Association path, not part of the classifier. The qualifier rectangle drags with the path segments. The qualifier is attached to the source end of the Association.
On this page
Association end properties
Name
Association End type
Qualifier
Editing the Association End properties
Defining Association End qualifiers
Defining Association End aggregation
Showing Association End properties
Converting Association End properties
Association navigability
Advancing actions: navigable owned Association Ends
Editing the Association End properties
To change the Association End type, do one of the following
On the diagram, select the Association End and move it to the other target. The Association is connected to the other target and the type of the Association End (that is, property) is changed.
In the Containment tree, select the property which represents the Association End and drag it onto the available classifier (the Association target). If the Association is represented on the diagram pane, the Association is redrawn (connected) to the changed target automatically.
In the property (that is, the Association End) Specification window, change the Type property value.
To define the Association End visibility
Open the Association End Specification window.
From the Visibility list, select one of the visibility type.
The Association End multiplicity describes how many entities are participating at each Association End:
0 – zero and only zero.
1 – one and only one.
0..1 – zero or one.
0..* – from zero to any positive integer.
1..* – from one to any positive integer.
* – any positive integer.
To place multiplicity values in Association path ends
Open the shortcut menu of a selected Association End and click a desired multiplicity.
Open Association’s shortcut menu, point to one of a desired Association End (Role of <class name>), and then click the desired multiplicity value.
Open the Association Specification window and, from the Multiplicity list, select or type the multiplicity value for the desired Association End.
Perform the following steps:
Open the Association End Specification window.
In the Multiplicity property value cell, type or select from the list a multiplicity value.
Edit directly on the diagram pane:
Select multiplicity area and press F2 to switch it to edit mode.
Press Ctrl + Spacebar or Ctrl + Backspace to see available suggestions.
Choose one of the suggestions or type the multiplicity value.
To define an Association End name
Open the shortcut menu of a selected Association End and click Edit Name. The Association End is marked for editing. Type or edit the name directly on the diagram pane.
Open the Association’s shortcut menu, point to one of a desired Association End (Role of <class name> ), and then click Edit Name. The Association End is marked for editing. Type or edit the name directly on the diagram pane.
Perform the following steps:
Open the selected Association End Specification window.
Type the Association End name in the Name property value cell.
Defining Association End qualifiers
A qualifier is an attribute or a list of attributes whose values serve to partition the set of instances associated with an instance across an Association. Qualifiers are attributes of an Association. It is represented as a small rectangle attached to the end of an Association path between the final path segment and the symbol of the classifier that it connects to. The qualifier rectangle is part of the Association path, not part of the classifier. The qualifier rectangle drags with the path segments. The qualifier is attached to the source end of the Association.
To add, edit, or remove a qualifier to/from an Association End
Open the Association End Specification window.
In the property group list, click the Qualifiers group and do one of the following:
To add a new qualifier, click the Create button. In the opened qualifier Specification window, define qualifier properties and click Back to return to the Association End Specification window or click Close to exit the Specification window.
To edit a qualifier, select a qualifier and edit its properties in the Association End Specification window or click the Open Specification button at the end of a qualifier row to edit qualifier properties in the qualifier Specification window.
Existing qualifiers are also displayed in the property group list under the Qualifiers group. Click the selected qualifier to open its Specification window, and define qualifier properties there.
To remove a qualifier, select a qualifier and click Delete.
After you have finished working with qualifiers, click Close to exit the Specification window.
Defining Association End aggregation
The shared or composite aggregation kind can be assigned to the Association End. A composite aggregation is represented as a filled diamond. A shared aggregation is represented as a hollow diamond.
To assign an aggregation kind to the association end
Open Association’s shortcut menu, point to one of a desired Association End (Role of <class name> ), and then select one of the following:
None. No aggregation is assigned to the selected Association End.
Shared.
Composite.
On the diagram palette, click the Composition or Aggregation button and draw an appropriate path on the diagram.
Right click the Association path end and select Shared or Composite command from the shortcut menu.
Perform the following steps:
Open the selected Association or Association End Specification window.
For the selected Association End, click Aggregation property value cell to select an aggregation kind (None, Shared, or Composite).
By default, the Aggregation property is in the All properties display mode.
Showing Association End properties
If two classes are linked with an Association path, both Classes have an attribute of an opposite Class type. This property can be displayed on the Class shape as well as an Association link.
To show Association Ends as attributes on linked Class shapes
From the Class shortcut menu, select Symbol Properties or press Alt+Enter. The Symbol Properties dialog opens.
In the Attribute category, click the Show Association End as Attributes property value cell.
Click one of the following display modes:
All. Properties and Association paths will be displayed on the Class shape.
Without Association Symbol. If an Association symbol is deleted, the property will be displayed on the Class shape.
Do Not Show. Neither property, nor Association path will be displayed on the Class shape.
An Association End is defined as a property. It has attribute properties defined in the Specification window.
To show Association Ends as Ports on the shape
Select the shape on which you want to display Association Ends as Ports and open its Symbol Properties dialog:
Right-click a shape to open the shortcut menu, and click Symbol Properties.
Press Alt+Enter.
In the Symbol Properties dialog, at the right-top corner, click to expand the menu and select the All mode.
Under the Ports category, click the Show Association Ends as Ports property cell and select All.
Converting Association End properties
To convert an Association role to an attribute
On a diagram pane, select an Association with a role.
From its shortcut menu, select the Refactor > Convert To > Attribute(s).
The Association is converted to the attribute.
You can specify Association End properties in the Association End Specification window. In the same window, you can find the description of each property. Descriptions are presented in the description area of the Specification window.
To convert association ends to ports
Right- click an Association End(s).
On the shortcut menu, click Refactor > Convert To > Port.
Association navigability
The Association navigability indicates whether it is possible to traverse an Association within an expression of a classifier to obtain the object or a set of objects associated with instances. The navigability is shown as an arrow that can be attached to the end of the path to indicate that the navigation is supported toward the classifier attached to the arrow.
By default, an Association is navigable on both sides and its navigability is not visible.
A role indicates the role played by the Class in terms of an Association. The role name is placed at the Association End, near the Class playing that role. The role name at the implementation level maps to the reference name of the opposite Class. Roles can have visibility (public, package, protected, and private).
To change the Association navigability, do one of the following
Open the Association End Specification window, turn on the Expert property display mode, and do one of the following:
Set the Navigable property value to true to mark the Association End as navigable.
Set the Navigable property value to false to mark the Association End as not navigable.
From the Association shortcut menu, select Role of <class name> and then do one of the following:
Select Navigable to mark the Association End as navigable.
Click to clear Navigable to mark the Association End as not navigable.
Open the Association End shortcut menu and do one of the following:
Select Navigable to mark the Association End as navigable.
Click to clear Navigable to mark the Association End as not navigable.
To display the Association navigability
From both Association Ends shortcut menu, select Show Navigability.
In the following figure, the Association is navigable on both sides and its navigability is visible.
Advancing actions: navigable owned Association Ends
The navigability describes the need for an object to access another object by navigating across the link. The Association End can be owned by a classifier or an Association. The Association End owned by a classifier can be decorated with the dot. The absence of the dot signifies the ownership by the Association.
In MagicDraw, the dot notation is not enabled by default. Please pay attention to this before making decisions about the Association End ownership just from the model representation on a diagram.
To enable a dot notation
On the Options menu, click Project. The Project Options dialog opens.
In the General options list, select General and set the Enable Dot Notation for Associations value to true.
According to the UML 2.4.1 specification, the Association Ends owned by Classes and Associations is navigable. This improved functionality allows a proper management of the navigableOwnedEnd property for Associations:
The ownership of an Association End can be changed manually.
The navigability of Association Ends owned by the Associations can be changed keeping the ownership.
To change the ownership of an Association End, do one of the following
On the Association End shortcut menu, click Owned By and then select the desired owner.
In the Association End Specification window, click the Owned By property value cell and then select the desired owner from the list.
From the Association shortcut menu, select the role of the desired Association End, click Owned By and then select the desired owner.
In the Association Specification window, click the Owned By property value cell of the role with the desired Association End and then select the desired owner from the list.
34.2、链接
.
| 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 |
34.3、项目应用
关联端就是两个东西有所关联，在项目中，就比如上面继承那个，教师类和学生类都跟人这个类有所关联。
35、Feature （特征）
35.1、原文
Feature, characteristic, peculiarity refer to a distinctive trait of an individual or of a class. Feature suggests an outstanding or marked property that attracts attention: Complete harmony was a feature of the convention. Characteristic means a distinguishing mark or quality (or one of such) always associated in one's mind with a particular person or thing: Defiance is one of his characteristics. Peculiarity means that distinct or unusual characteristic that marks off an individual in the class to which he, she, or it belongs: A blue-black tongue is a peculiarity of the chow chow.
35.2、链接
| https://www.dictionary.com/browse/feature |
| https://www.collinsdictionary.com/dictionary/english/feature |
| https://www.tenforums.com/tutorials/7247-turn-windows-features-off-windows-10-a.html |
35.3、项目应用.
同样要为数据字典中的ER图实体设计其相应的属性，如：在用户表中我们设计了编号（id），用户名（nickname），密码（password），角色（role），手机号（phone_number）等等属性来为用户设定相应的特征
36、Behavior（行为）
36.1、原文
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:
Classifier Behavior - the native behavior that is initiated when a Block is instantiated
Behavior Features - these are the Operations and Receptions (and their related Signals)
We will look at these different behaviors in the next sections of the Guide, but it is important to understand that they will work in unison, coordinated by system interactions that will ensure that the operations are called in sequence and that the Signals are received and acted upon by the Receptions.
A Blocks Classifier Behavior
A Block has the potential to do work but by itself it is a somewhat latent entity and needs to be commanded into action by some type of call to its operations or the receipt of a signal, state change or other behavioral trigger. A Block has a concept of its native or classifier behavior, as it is formally called. This diagram shows a Block in the Browser window that has a nested Activity that will be defined as the Classifier Behavior for the Block.
To select this behavior for the classifier behavior open the Properties window and change the Classifier Behavior property by selecting the [...] icon and locating the appropriate Behavior (Activity) as indicated in the screen-shot.
Operations as Behavioral Features
Blocks can define operations essentially as the 'muscles' of the Block, as it is the operations that do most of the work required of the system. In Enterprise Architect an engineer can access the operations from a number of points in the user interface, but all of these points will open the Features window, which lists the operations on the 'Operations' tab as shown here:
The Features window is useful as a summary of all the structural and behavioral features, including Parts and Interaction Points owned by the Block. The easiest way to create an operation is to select the Block in a diagram or in the Browser window and click on the ribbon item:
Design > Element > Editor > Features > Operations
Operations are simply created by selecting the 'Operations' tab and adding the name and other details in a row of the window. Any number of operations can be created, and each operation can define any number of parameters, which specify the inputs and outputs to the operation. Their importance will be discussed later in this section when we describe the relationship between Activity Parameters and Action Pins. Operations can also be displayed in a diagram, either on their own or with other features, each type of which is displayed in a separate compartment of the parent element.
There is a wide range of options that govern how the operations are displayed, including the ability not to display the entire compartment or to only display particular operations by suppressing others from display.
This will result in selected operations being hidden on the diagram, which is a very useful presentation device as it helps an engineer create a diagram focused on a particular aspect of the Block, suppressing or hiding irrelevant and distracting content. This diagram fragment shows the result of suppressing operations:
The same can be done for attributes at an element level, and a similar function is available to suppress particular operations, attributes and Tagged Values at a diagram level. An engineer might use the diagram-level function when there is a particular operation that appears on multiple Blocks and they want to suppress it for every element in the diagram.
Operations can be invoked in two modes, either synchronously or asynchronously, and can be initiated in a number of different ways depending on the type of behavior that is orchestrating the systems behavior, including:
A Call Operation Action (invocation of an Activity)
A Message as part of an Interaction (Sequence diagram)
A StateMachine
This means that the operation can be visualized in a range of SysML diagrams and will appear differently in different contexts. For example, in a Sequence diagram where messages are sent between instances of Blocks or other classifiers, the operation will appear as an annotation to one of the Block's incoming messages to show that the operation will be initialized as a result of the message. Enterprise Architect allows an engineer to access the Block's operation list directly from this diagram and will also allow operations to be created directly from the diagram.
In the case of the Call Operation Action, the element's Pins must be aligned by type and name to the called operation's parameters; Enterprise Architect helps you visualize this mapping on a diagram, using the 'Link to Feature' facility.
Receptions as Behavioral Features
Receptions are another behavioral feature of a Block but, in contrast to an operation, Receptions can only be called asynchronously. Receptions also work differently to operations in that an Operation Call specifically identifies an operation to be invoked, whereas the receipt of an instance of a Signal is deemed to be a request for any Reception of the receiving object that references that Signal or any direct or indirect generalization of it. In this way there is a level of indirection between the calling element and the Reception. A Reception has parameters corresponding to the attributes of the Signal referenced by the Reception, and these are considered as 'in' parameters of the Reception.
The easiest way to create a Reception is to click on the Block in a diagram or in the Browser window and select the ribbon item 'Design > Element > Editor > Receptions'.
To create a new Reception you must first have created the appropriate Signal to relate the Reception to. When you create the Reception you will be prompted to locate the appropriate Signal in the Browser window as shown here:
Receptions, like operations, can be displayed in a specialized compartment in a Block on a diagram. It is possible to customize the display and suppress all Receptions or configure which particular Receptions are displayed. In this screen capture the engineer has decided to make all Receptions visible, but each diagram and each Block within a diagram can be configured differently.
36.2、链接
| https://support.microsoft.com/en-us/help/10164/fix-windows-update-errors |
| https://www.w3school.com.cn/php/func_error_reporting.asp |
| https://blog.csdn.net/weixin_44517500/article/details/99683286 |
36.3、项目应用
项目会有很多行为，比如我们项目中学生查询成绩是一个行为，教师查询学生是一个行为，教师录入成绩是一个行为，行为在项目中无处不在。
37、distribution unit（分配装置）
37.1、原文
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）是一种电气组件，用于分配和管理数据中心环境中计算机，服务器和网络设备的电力供应。它提供了一个中央单元，用于控制和分配数据中心各个组件之间的电力。
37.2、链接
| 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 |
37.3、项目应用
有一说一，这个词我不太懂是什么意思，对于我们项目，这个知识点也没有使用，后续会继续学习这个词，把这个知识点运用到该用的地方去。
38、development process（开发流程）
38.1、原文
Product development is the first stage in the product life cycle, and when you want to develop a product for selling online, you need to think like Bezos and systematically analyze product, market, and distribution characteristics in order to build your business plan.
The product development process is composed of the steps that transform a product concept into marketable merchandise. You start with an idea and end up with technical specifications, product positioning, pricing strategy, service components, and financial characteristics.
At its outset, this process can be idea-driven or market-driven, but it mostly follows the same steps.
38.2、链接
| 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 |
38.3、项目应用
开发流程的话是每个项目都要去制定的，一个项目刚开始就是要了解用户的需求，也就是我们现在正在学的需求工程，了解完需求后根据需要制定开发任务，包括编码和测试等流程。
39、binary association（二元关联关系）
39.1、原文
A one-to-one binary relationship between two entities is illustrated in Figure 5.1(a)–(c). Note that the UML-equivalent binary association is given in Figure 5.2(a)–(c).
When both entities are mandatory (Figure 5.1a), each entity becomes a table, and the key of either entity can appear in the other entity's table as a foreign key. One of the entities in an optional relationship (see Department in Figure 5.1b) should contain the foreign key of the other entity in its transformed table. Employee, the other entity in Figure 5.1(b), could also contain a foreign key (dept_no) with nulls allowed, but this would require more storage space because of the much greater number of Employee entity instances than Department instances. When both entities are optional (Figure 5.1c), either entity can contain the embedded foreign key of the other entity, with nulls allowed in the foreign keys.
The one-to-many relationship can be shown as either mandatory or optional on the “many” side, without affecting the transformation. On the “one” side it may be either mandatory (Figure 5.1d) or optional (Figure 5.1e). In all cases the foreign key must appear on the “many” side, which represents the child entity, with nulls allowed for foreign keys only in the optional “one” case. Foreign key constraints are set according to the specific meaning of the relationship and may vary from one relationship to another.
The many-to-many relationship, shown in Figure 5.1(f) as optional for both entities, requires a new table containing the primary keys of both entities. The same transformation applies to either the optional or mandatory case, including the fact that the “not null” clause must appear for the foreign keys in both cases. Note also that an optional entity means that the SQL table derived from it may have zero rows for that particular relationship. This does not affect “null” or “not null” in the table definition.
Marco Brambilla, Piero Fraternali, in Interaction Flow Modeling Language, 2015
Most domain modeling languages, including UML, admit the specification of associations involving more than two classes, called N-ary associations, and of associations with attributes, represented with association classes. However, these constructs are less intuitive than binary relationships and also raise interpretation problems, such as those related to the meaning of multiplicity annotations [GLM01].
However, it is well known from the data modeling field that both these constructs can be represented using a combination of classes and binary associations. This practice requires slightly more modeling effort but makes the diagram interpretation more intuitive.
Figure 3.10 and Figure 3.11 show the representation of N-ary associations (actually ternary, for the sake of illustration) with equivalent binary associations and classes.
Sign in to download full-size image
Figure 3.10. N-ary associations as a primitive construct (left) and as binary associations and classes (right).
39.2、链接
| https://www.sciencedirect.com/topics/computer-science/binary-association |
| https://binaryterms.com/link-and-association.html |
| https://en.wikipedia.org/wiki/Class_diagram |
39.3、项目应用
设S是一个非空集合,R是关于S的元素的一个条件.如果对S中任意一个有序元素对（a,b）,我们总能确定a与b是否满足条件R,就称R是S的一个关系（relation）.如果a与b满足条件R,则称a与b满足条件R,则称a与b有关系R,记做aRb;否则称a与b无关系R.关系R也成为二元关系.本项目中拥有的二元关系也有很多，而且也符合我们日常生活中的逻辑。
40、postcondition（后置条件）
40.1、原文
It is feasible to extract interrupt-related preconditions and postconditions from both source code and comments written in a natural language. This section uses examples to explain how aComment extracts postconditions and preconditions from comments and code. For postconditions, if one knows that local_irq_disable disables interrupts, one can infer that all functions that call local_irq_disable but not any interrupt-enabling function also disable interrupts.
aComment infers preconditions from both comments and code assertions. First, aComment infers preconditions from comments. For example, the comment in Figure 17.6a states that interrupts must be disabled before calling tick_init_highres. By combing keyword search and domain-specific knowledge, aComment converts this comment into the annotation /* @IRQ (0, X) */, where 0 indicates that interrupts must be disabled before calling the function, and X indicates that interrupts can be either disabled or enabled on exit of this function (Figure 17.6b). The postcondition, X, will be refined during the annotation propagation process.
40.2、链接
| https://www.tutorialspoint.com/software_testing_dictionary/post_condition.htm |
| https://www.sciencedirect.com/topics/computer-science/postconditions |
|
|
40.3、项目应用
后置条件也可以为我们带来许多方便。例如：在教师录入学生成绩时，录入后的成绩必须是true，才能继续执行下一次学生的录入，学生也才能查询的到成绩。
《需求工程——软件建模与分析》这门课对我影响挺大的。虽然上个学期已经学了一些这方面的知识，但是并不是很系统。希望可以通过这本书整理一下。
读软件需求分析首先明确了软件需求包含的三个不同层次，业务需求即组织机构或客户的需求目标，用户需求即用户使用产品必须要完成的任务，功能需求即开发人员需要实现的软件功能。从需求的定义上我们可以知道需求关注的是究竟想开发什么与设计细节实现细节项目规划信息或者测试信息无关，不重视需求过程会给项目带来极大风险，所以在需求过程中我们要注意避免以下几种情况，无足够用户参与，用户需求不断扩展，用户需求不明确或者说模棱两可，不必要的特性即为软件画蛇添足，过于精简的规格说明，忽略了用户分类，不准确的计划，而高质量的需求过程要求产品开发过程中的通力合作同时充分了解其市场，因此要想完成一份优秀的需求就必须具备完整性（功能完整），正确性（准确陈述其功能），可行性，必要性（每项需求都硬把客户真正需要的和最终系统），划分优先级，无二义性（只能有一个明确统一的解释），可验证性等特性。同时需求规格说明也需具备完整性，一致性，可修改性，可跟踪性（即每项软件需求与它的根源和设计元素，源代码，测试用例之间建立起链接链）。
那么什么是需求工程？需求工程是所有需求处理活动的综合，它收集信息、分析问题、整合挂点、记录需求并验证其正确性，最终反应软件被应用后与其环境互动形成的期望效应。需求工程是为了在软件开发前需要软件工程师们去了解并去设计出一套解决方案。因为软件工程师并不是了解所有领域。所以更加需要更用户沟通。需求工程十分重要。虽然人们很早就认识到这一点，但是在时间、人力、物力、财力的投入上却并没有那么重要。事后必然会导致需求分析水平低，软件开发质量低，用户抱怨多的问题出现。
为了解决这样的问题需求分析师们必须具备以下技能以方便、明确、成功的做出需求分析：
1.需要专业技能，懂得需求工程的相关知识、理解需求工程的相关理论、熟悉需求工程的各项活动、掌握需求工程的各种办法与技术是必须得；
2.是要有分析技能，必须可以从大量信息中提取、分析、整合出有用的信息处理，了解用户需求中的冲突与遗漏，分析可行性；
3.需要交流技能，这是必须的，要掌握交谈和提问的技巧，否则很难跟不懂软件的客户出现隔阂，隔行如隔山，大家不能各说各的吧；
4.观察技能、建模技能、写作技能、创新技能、协调技能等。需求工程师应该具有敏锐的洞察力，可以通过观察用户的工作环境和工作过程，发现通过谈话及其他方法所无法发现的重要信息。同时也应该掌握从传统流程图到结构化的分析模型，直至当今的统一建模语言等多种分析工具。因为需要跟客户、管理人员、开发人员等交涉信息，所以需要写好书面的需求规格说明书。写作技能是必须的。需求工程师需要通过写作清晰的表达出复杂的概念。
项目的目标是系统的业务需求。在很多情况下，涉众可以清晰地表达出系统的业务需求，这时可以通过安排和涉众的面谈来明确项目的动机。但也有很多情况下，涉众无法表达他们的业务需求，或者表达的业务需求不够清晰。因此，要发现系统的业务需求，还是要从用户的问题开始。要分析涉众的问题，首先要明确问题，将它们变得清晰，变得适宜进行分析。这个过程从问题和相关的背景描述开始。
从问题来说，我们要清楚客户需要我们到底是要干什么，不能盲目一抹瞎，想当然的做需求分析报告，要清楚客户需要解决哪些问题，要我们做出什么样的功能，使用者与审核者是谁这是要弄清楚的，这就涉及到了我们双方在审核一个问题的时候需要有着同样的标准，具体的方法就是用标准化的格式描述问题，并在涉众之间取得认同。达成共识的问题是一致的问题，但一致的问题不一定是明确的问题。问题的明确性要求它们具有易于理解和能指明解决方向两个特点。
接下来是背景，可能有的时候与客户打交道的时候，他们或许不清楚他们到底需要的是一个什么样的软件，许多客户对计算机其实都不太懂得太多，他们或许只是按照领导或上面的这是来完成工作，只知道我需要做出的是一款什么样子，拥有什么样的功能，这往往有时候就十分的空旷，这个时候就需要我们来深入了解客户使用这一款软件的时候是在什么样的背景中，他们需要什么，是为了什么情况的时候而需要，所以在这个时候，我们需要用心记录下客户及领导之间的对话，要学会快速记笔录，也许你需要的信息就在对话中就透露出来了。
所以说需求过程是软件项目成功的关键所在，当其他项目过程变更时会对需求过程的影响下面列举了一些变更会产生影响的项目过程：制定项目计划过程（在基线确定前缩小项目范围或采用版本计划从而使项目计划在允许的资源和时间内完成），项目跟踪和控制过程，变更控制过程，系统测试过程（验证计划中的功能是否按期完成）用户编制文档过程（要编写出用户显示界面及性能的最终变更版本），构造过程。
这是第一次比较系统的学习如何对一个项目进行需求分析，所以肯定会有很多地方存在不足与缺陷，希望通过后期的改进使我们的需求更加清晰。比如我们可以在用户的视觉效果进行改进，观感需求一些与产品的用户界面相关的需求描述，从而使自己设计的产品更符合用户的观感体验；我们还可以从产品的使用复杂性去靠拢，如何使我们的项目更容易使用；从长远目光看，我们还得考虑一下性能方面的要求，如何才能适应高并发；还有一点也是最重要的就是安全，我们要保证用户的信息安全，不能让用户的信息外流。对于规范需求分析的方法，这里我打算采用原型方法，传统的软件工程方法强调自顶向下分阶段开发，要求在进入实际开发期之前必须预先对需求严格定义。但实践表明，在系统建立起来之前很难紧紧依靠分析就确定出一套完整、一致、有效的应用需求，并且这种预先定义的策略更不能适应用户需求不断变化的情况。由此，原型法应运而生，它一反传统的自顶向下的开发模式，是目前较流行的使用开发模式。原型分析优点，(1)增进软件开发者和用户对需求的理解，使比较含糊的具有不确定性的软件需求(主要功能性的需求)明确化。(2)软件原型化方法提供了一种有力的学习手段。(3)使用原型化方法，可以容易地确定系统的性能，确认系统主要服务的可应用性，确认系统设计的可行性，确认系统最终作为产品。原型建立技术，(1)可执行规格说明。它是基于需求规格说明的一种自动化技术，使用这种方法，人们可以直接观察用语言规定的任何系统的功能和行为。(2)基于脚本的设计。脚本是用户界面的原型。一个脚本用来模拟在系统运行期间用户经历的事件。它提供了输入——处理——输出的屏幕格式和有关对话的模型。因此，软件开发者能够给用户显示系统的逼真的视图，使用户得以判断是否符合他的意图。(3)自动程序设计在程序自动生成环境的支持下，利用计算机实现软件的开发。它可以自动地或半自动地把用户的非过程式问题规格说明转换为某种高级语言程序。(4)专用语言。专用语言是应用领域的模型化语言。在原型开发中使用专用语言，可方便用户和软件开发者对系统特性进行交流。(5)可复用的软件。利用可复用的模块，通过适当的组合，构造的原型系统。为了快速地构造原型，这些模块首先必须有简单而清晰的界面;其次它们应当尽量不依赖其它的模块或数据结构;最后，它们应具有一些通用的功能。(6)简化假设。 简化假设使设计者迅速得到一个简化的系统。尽管这些假设可能实际上并不能成立，但它们可以使开发者的注意力集中在一些主要的方面。在修改一个文件时，可以假设这个文件确实存在。 在存取文件时，待存取的记录总是存在。一旦计划中的系统满足用户所有的要求，就可以撤消这些假设，并追加一些细节。
用户的需求是与时俱进的，时刻都可能发生改变，用户随时会提出一些新的需求，要求开发人员解决，这些需求的提出，有时在开发阶段中有时在开发阶段后。这种在需求分析的两个相邻子阶段中，或者在迭代周期的需求分析中，后一段或周期的需求分析结果与前一次不一致，这就是需求的变更。产生需求变更的原因主要有以下几个方面：(1)在需求分析阶段，开发人员与用户的沟通不够。在需求分析阶段，开发方与用户没有很好的交流，开发方就根据用户提供的大概信息，自己推导出用户的需求。通过这种需求分析得出的需求往往会和用户的实际需求相差甚远，导致用户提出更改需求。(2)项目的实施周期过长。随着时间的推移，用户对整个系统的了解也越来越深入。他们会对模块的界面、功能和性能方面提出更高更多的要求。(3)技术更新过快。由于技术的快速更新， 企业可能引进一些新的设备， 而这些设备可能就会与我们的目标系统有直接的关系， 由于这一变化可能发生在解决用户原先问题之前或者之中， 那么开发人员不得不加入这一新的需求。对于这个问题，我们可以设置一下需求基线，来最大程度的使变化最少，最大程度的节约劳动力，以最短的时间，最快的效率来完成任务。
《需求工程--软件建模与分析》（第2版）
博客地址：https://blog.csdn.net/Rralazy
标签：www,End,A002,diagram,https,185,2532,com,Association 来源： https://blog.csdn.net/Rralazy/article/details/111958651