A002-182-2259
知识整合
A:
Active object
拥有线程并可以启动控制活动的对象。不需要接收消息便可执行其自身行为的对象。即一种拥有自己的控制线程的对象。
https://blog.csdn.net/my98800/article/details/52327346
C:
Concurrency
并发性（Concurrence）是指在一个系统中，拥有多个计算，这些计算有同时执行的特性，而且他们之间有着潜在的交互。因此系统可进行的运行路径会有相当多个，而且结果可能具有不确定性。并发计算可能会在具备多核心的同一个芯片中复合运行，以优先分时线程在同一个处理器中运行，或在不同的处理器执行。
https://blog.csdn.net/xiangxianghehe/article/details/80200856
D:
development view
视图，拆成两个字，一个是视，一个是图;视，顾名思义就是视角，之所以会有不同的视角，是因为软件架构是有不同的消费者的，例如用户、设计者、管理者、系统工程师、维护人员等等。对于这些不同的利益相关者，他们看同一个架构的视角自然是不一样的。图，意思就是一个整体的图式，它是某一视角下软件架构的一个完整的展现。
https://zhuanlan.zhihu.com/p/97774419
E:
Emergent properties
紧急属性是由于各种系统组件协同工作而表现出来的属性，而不是任何单个组件的属性。
https://sciencing.com/emergent-properties-8232868.html
F
functional requirements
中文：功能需求
解释：功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。注意：用户需求不总是被转变成功能需求。产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。
https://blog.csdn.net/qinhl99/article/details/5509004
G:
guard condition
一种必须满足的条件，才能使相关的转换为开火.
单波段是单一调幅中波收音机或调频收音机。每个波段都有不同的调节范围，每个范围内在特定的频率有特定的电台。限制波段的一些收音机，比如我们用的手机上的收音机(只有调频)，录音机上的收音功能(中波和调频)，在一些场合表现比全波段收音机要好。
https://www.allinterview.com/showanswers/13930/what-is-guard-condition.html
L:
logic view
主要支持系统的功能需求.
M:
Metamodel
定义用于表示模型的语言的模型。
https://blog.csdn.net/jimoshazhouleng360/article/details/32142269
N:
Node
网络连接的端点，或两条（或多条）线路的连接点。结点可以是处理器、控制器或工作站。结点随其功能不同而各不相同，它们可以通过链路互联在一起，在网络中用作控制点。
https://baike.baidu.com/item/node/4689680?fr=aladdin
P：
primitive type
没有任何子结构（如整数或字符串）的预定义基本数据类型。
编译器直接支持的数据类型称为基元类型（primitive type).基元类型和.NET框架类型（FCL)中的类型有直接的映射关系，例如：在C#中，int直接映射为System.Int32类型。
https://blog.csdn.net/tounaobun/article/details/8226930
Q
quality attribute
质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。还有一项称为可用性（usability）的质量属性，它规定了业务需求中“有效”（efficiently）一词的含义。
https://blog.csdn.net/qinhl99/article/details/5509004
S:
state diagram
描述一个状态机. 状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应。通常我们创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。
T:
timing diagram
强调消息跨越不同对象或角色的实际关系
一种交互图。表示对象中的事件发生和对象之间相互作用的时刻，以及由此引起的对象状态变化的时刻和持续时间。
一、我的需求分析与建模读书心得
引言
通过本学期学习需求工程——软件建模与分析，比较清晰的了解什么需求分析与获取，然后通过什么方式去实现应有的功能和需求。自我认为总体可以分为四大块：需求获取方法等、建模、需求规格说明、需求验证。
首先，需求分析阶段的任务是确定软件系统功能。软件需求分析是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。软件需求分析是一个项目的开端，也是项目实施最重要的关键点。
例如：软件描述：软件的功能以及软件操作上的约束必须定义；软件设计与软件实现：软件一定要按照描述来生产；软件有效性验证：软件要被确定是有效的，能做客户想要做的事情才可以；软件进化：软件一定要按照客户的变化与跟进来进化。其中，软件描述，目标是确定软件系统需要哪些服务以及开发和运行期间受到哪些约束。对服务和约束的发现、分析、建立文档、验证活动现在常称为需求工程。
1.需求获取方法之一——面试
需求获取的方法之一是面谈，利用面谈可以获得事实和问题，被会见者的观点，被会见者的感受，组织和个人的目标。面谈中包括两种基本问题类型，开放式问题和封闭式问题，各有优缺点。面谈结构包括金字塔结构，即封闭问题到开放问题的过度结构。漏斗结构，即开放到封闭结构。菱形结构，前两种结构的结合。除了开放问题和封闭问题，还有探究式问题，诱导性问题，双筒问题，元问题，程序性提示等几个其他重要的问题类型。在面谈之前，需要做阅读背景资料，确定面谈主题和目标，选择被会见者，准备被会见者，确定问题和类型等准备。面谈中需要建立一个理想氛围和环境，保持有礼貌的倾听，控制面谈过程，保持面谈主题，使用探究式问题，观察被会见者，使用道具支持。结束后感谢被会见者。记录面谈可以采用笔录，录音摄像（征得被会见者的同意）。面谈结束需要复查面谈记录，总结面谈信息，完成面谈报告。面谈包括结构化面谈，半结构化面谈，非结构化面谈等几个方面。还有群体面谈。除了面谈，还有调查问卷，头脑风暴等方式。
2.建模
在需求分析中，建立软件分析模型，可以帮助达成开发者和用户对需求信息的共同理解，有了共同理解，就可以创造软件系统解决方案。
“模型是对事物的抽象，帮助人们在创造一个事物之前可以有更好的理解”。建立软件模型可以降低应用的复杂性、更深刻的理解信息、帮助人们更好的记忆细节、更好的与其他开发人员进行交流、更好地与用户以及其他涉众进行交流、为以后的维护和升级提供文档。
计算机世界是基于计算机科学建立的，具有形式化的特征。计算机模型对信息描述具有明确化、准确化和确定花的特征，但在需求工程阶段，软件系统需要解决的问题，缺乏和软件实现相关的技术细节是考虑的重点，因此，需求分析阶段还无法建立一个形式化的计算模型。业务模型既可以抽取出需求信息最重要和最本质的内容，又可以达成用户和开发者的共同理解，但是问题世界的非形式化特征却使得它同样也不适合于需求建模。分析模型以对象、类、函数、过程、属性等作为模型的基本元素。分析模型在组元的表现上采用了业务模型的表现方式，使用业务概念、业务联系和问题与语言来表现组元的语义，这样的分析模型利于被用户和开发者同时理解。
模型可以表现为抽象知识体、视图、模型语言等，复杂的应用应该从多个视角分别进行建模，需要多种技术相互配合使用。需求分析技术多种多样，要把握每种技术的内涵，不仅需要广泛的阅读，还要进行很多的实践。
模型语言有语法，语义和语用。常见的需求分析技术包括，上下文图，数据流图，实体联系图，功能实体矩阵，功能分解图，过程依赖图，用例图，类图等uml建模过程。常见需求分析技术，可以通过wieringa和zachman进行分类（书p206/209）。需求分析方法有传统分析，结构化分析，信息工程和面向对象分析。实践中的需求分析需要需求分析技术的使用，非功能需求的建模，确定需求优先级，新技术方法的需要等。
过程建模是结构化分析方法的典型技术，也就是分析需求获取活动获得的信息，发现系统的功能和其与外界的交互，建立能够实现系统功能的过程分解结构，形成系统的过程模型，并用图形的方式将过程模型描述出来。过程建模使用的主要技术有:上下文图，数据流图，微规格说明（过程规范），数据字典。因为已经学过uml建模，大致理解各个方面。最后是逻辑DFD，物理DFD与传统的DFD三种建模方法的区别和优缺点。
过程模型更多的是侧重数据产生与使用的时间，地点和方式，而没有描述数据的定义，结构和关系等特性。数据建模就是描述的后者。数据建模包括概念，物理和逻辑数据模型。使用ERD描述数据模型的方法，ERD的创建方法主要有三种：依据充分描述信息的创建，依据硬数据表单的创建，复杂情况下的创建。现在实现ERD与过程模型同步的技术中，功能/实体矩阵是一种比较常见的技术。 面向对象建模就是有关uml的各种图和建模方式的描述。
3.需求规格说明
传统分析方法根本没有什么方法论，需求工作人员根据自己的个人习惯等进行建模和分析工作，使得结果存在着冗长、混乱、偏颇、无结构等问题。结构化分析方法是在形式化技术奠定计算机科学学科知识后，人们为寻找解决传统分析方法下的问题形成的，他通过数据流图、实体联系图、状态转移图等等对系统建模。随着人们对数据日益重视以及数据库管理系统的兴起，信息工程出现了，它与结构化方法不同之处在于，结构化主张功能入手，信息工程主张数据入手。面向对象分析方法受到了结构化分析方法的很多影响。
需求规格说明活动是在标准模板的基础上，依据自身项目特点对文档模板进行剪裁和调整得到需求规格说明文档模板，加入系统模型知识和系统需求知识形成软件需求规格说明书。编写需求规格说明文档的必要性是显而易见的：清晰、明确、结构化的文档可以将软件系统的需求信息和解决方案更好的传递给所有的开发者；文档可以拓展人们的只是记忆能力。需求规格说明书文档还有很多好处：例如，可以成为各方人员之间有关软件系统的协议基准，可以成为项目开发活动的一个重要依据，在编写过程中可以尽早的发现和减少可能性的需求错误，从而减少项目返工，降低项目工作量，可以成为有效的智力资产。
4.寻求验证
软件测试使人们最熟悉和常用软件质量保障措施，他以考察正在执行的软件的输入输出或者功能来验证软件的质量。软件系统的质量保障要求在实际可执行的代码产生之前，要尽可能的依据开发文档、模型或者其他各种可用物件进行分析和推理，及早地发现错误并进行修正，这种方法被称为静态分析。
参与评审的人员的任务都是查找缺陷和对其进行改进的机会。审查者要扮演组织者、仲裁者、作者、阅读人员、记录人员、收集人员、审查人员等等角色。在验证过程中发现的问题都应该及时修正，修正行为有需求澄清、发现缺失需求、解决需求冲突、修正不切实际的期望。
二、我对我组项目的发展建议：
因为对开发软件的不熟悉以及系统配置等各种问题，我们消耗了太多时间在准备工作上，导致进度缓慢， 建议不要贪多，先从熟悉开发环境开始，在网上找一些书籍或者教学视频什么的，先学习，在开始开发。另外软件方面的建议，基本的就是资料的上传下载，还有及时更新问题。实现基本的网页设计，以及各网页间的参数传递，完成各网页和数据库之间的联系。已经完成了两个网页的设计，实现评论和查找功能，链接数据库等功能。要做的还有很多，还是需要慢慢去挖掘与学习。
浙公网安备 33010602011771号