个人作业——A002-185-2515-郑远曦

计算机科学与工程学院实验报告（首页）
课程名称 软件需求分析与建模 班级 18软件工程5班
实验名称 Excel查找结合项目主题说明 教导教师 董瑞生
姓名 郑远曦 学号 1814080902515 日期 2020．12.20

目录
1.作业查词说明 1
1.1 software reuse(软件复用). 3
1.2 aggregate class(聚合类) 4
1.3 decision table(判定表) 4
1.4 functional requirement(功能性需求) 6
1.5 Requirements baseline(需求基线) 7
1.6 state-transition diagram(状态转换图) 8
1.7 behavioral model aspect(模型的行为侧重面) 10
1.8 binary association(二元关联) 10
1.9 association end(关联端点) 11
1.10 collanoration diagram(协作图) 11
1.11 deployment diagram(部署图) 12
1.12 focus of control(控制焦点) 15
1.13 generalization(泛化) 15
1.14 implementation view(开发视图) 16
1.15 incremental development(增量开发) 17
1.16 interaction diagram(交互图) 18
1.17 logical view(逻辑视图) 19
1.18 model element(模型元素) 20
1.19 multiple classification(复合分类) 20
1.20 multiple inheritance(多继承) 21
1.21 n-ary association(N-Ary关联) 22
1.22 Logical Cohesion(逻辑内聚) 22
1.23 Temporal Cohesion(时序内聚) 23
1.24 Functional Cohesion（功能内聚） 24
1.25 Informational Cohesion(信息性内聚) 25
1.26 Common Coupling(公共耦合) 26
1.27 Data encapsulation(封装) 26
1.28 Corrective Maintenance(改正性维护) 28
1.29 Avoidance strategies(规避策略) 29
1.30 business reengineering(业务流程重组) 30
1.31 class hierarchy(多重继承) 31
1.32 concurrent substate(子状态) 32
1.33 containment hierarchy(容器分层结构) 33
1.34 defect density(缺陷密度) 35
1.35 design subsystem(设计子系统) 36
1.36 distributed processing(分布式处理) 37
1.37 generalizable element(可泛化元素) 38
1.38 interface inheritance(接口继承) 39
1.39 Pseudo-classes(伪类) 41
1.40 Process Asset Library(过程资产库) 42
1.41 Software Requirements Specifications(软件需求规格说明) 43
1.42 tagged value(标记值) 44
1.43 use-case diagram(用例图) 44
1.44 actor-generalization(主角泛化关系) 45
1.45 architectural pattern(架构模式) 45
1.46 Agile Processes(敏捷开发) 47
1.47 rapid prototype(快速原型模型) 48
1.48 Content Coupling(内容耦合) 48
1.49 External Coupling(外部耦合) 50
1.50 Control Coupling (控制耦合) 50
2.读书笔记 55
《需求工程—软件建模与分析》读后感 55
3.对项目的发展建议 56
对绿小萝项目的发展建议 56

1. 作业查词说明
   1.1 software reuse(软件复用)
   名词解释：software reuse as “the systematic use of existing software assets to construct new or modified assets.
   详细解释：软件复用(softwarereuse) : 提高软件生产力和质量的一种技术，将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。软件复用是一种计算机软件工程方法和理论。60年代的“软件危机”使程序设计人员明白难于维护的软件成本是极其高昂的，当软件的规模不断扩大时，这种软件的综合成本可以说是没有人能负担的，并且即使投入了高昂的资金也难以得到可靠的产品，而软件重用的思想是解决这一问题的根本方法。
   1.2 aggregate class(聚合类)
   名词解释：A class that represents the "whole"in an aggregation (whole-part)relationship.
   详细解释：在软件开发中也存在类似于电视机一样的类，他们可以存储了多个成员对象（元素），这些类通常称为聚合类（Aggregate Class），对应的对象称为聚合对象。聚合类使得用户可以直接访问成员，并且具有特殊的初始化语法形式。当一个类满足如下条件时，我们说它是聚合的：
   ·所有成员都是public的。
   ·没有定义任何构造函数。
   ·没有类内初始值。
   ·没有基类，也没有virtual函数。
   1.3 decision table
   名词解释：A tabular,systematic representation of a complex decision that depends on multiple criteria
   详细解释：判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具。在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了。由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。
   判定表通常由四个部分组成。
   条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出得条件的次序无关紧要。
   动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
   条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
   动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
   规则：任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。
   判定表的建立步骤（根据软件规格说明）：

1. 确定规则的个数。假如有n个条件，每个条件有两个取值（0，1），故有n2种规则。
2. 列出所有的条件桩和动作桩。
3. 填入条件项。
4. 填入动作项。等到初始判定表。
5. 简化。合并相似规则（相同动作）。
   Beizer 指出了适合使用判定表设计测试用例的条件：
6. 规格说明以判定表形式给出，或很容易转换成判定表。
7. 条件的排列顺序不会也不影响执行哪些操作。
8. 规则的排列顺序不会也不影响执行哪些操作。
9. 每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
10. 如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。
    1.4 functional requirement(功能性需求)
    名词解释：A requirement concerning a result of behavior that shall be provided by a function of a system(or of a component or service)
    详细解释：功能需求 （functional requirement规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求 （behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什 么。注意：用户需求不总是被转变成功能需求。产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标 得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用 户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。
    1.5 Requirements baseline(需求基线)
    名词解释：A baseline for a set of requirements
    详细解释：需求基线就是把固定的需求都划一根“线”,说明这些需求已经确定下来，添加新的需求或修改原有的需求都必须通过需求变更流程来操作建立需求基线的目的：防止需求的变化给程序架构造成重大影响。
    需求基线定义：已经通过正式评审和批准的规格说明或产品，可作为进一步开发的基础，而且只有通过正式的变更控制过程才能修改它。
    需求基线要以一种持续、衡定和易于项目涉众访问的方式存在。需求基线通常以文档的方式纳入配置管理中。需求基线的内容：标识符：为后续的项目工作提供一个共同的交流参照；当前版本号：保证项目的各项工作都建立在最新的一致需求基础之上；源头：在需求进一步深入理解或者改变需求时，可以回溯到需求的源头；理由：提供需求产生的背景知识；优先级：后续的项目工作可以参照优先级进行安排和调度；状态：交流和具体需求相关的项目工作情况；成本、工作量、风险和可变性：为需求的设计和实现提供参考信息，驱动设计和实现工作。其他需求创建的日期和需求相关的项目工作人员需求涉及的子系统需求涉及的产品版本号需求的验收和验证标准需求基线的维护：要合理地控制对需求的更改要维持需求多个版本情况下的正确使用需求基线的内容是项目的共享资产的工作基础，它应该实现统一的管理。配置管理包括：标识配置项版本控制变更控制访问审计状态报告。
    1.6 state-transition diagram(状态转换图)
    名词解释：A diagrammatic representation of a state machine
    详细解释：状态转换的要素
    状态：
    tcp定义的11个状态
    事件：
    触发TCP状态迁移。事件能够是：本地应用层调用。收到TCP消息(incoming segment)；超时事件(timeout)
    动作:
    主要指针对远程Peer产生的动作，如发送确认等。
    转换中的角色
    本地应用层 Local App：产生事件。
    本地tcp实现层 local TCP stack:处理事件。完毕状态转换；在远程tcp上产生事件。
    远程tcp实现层 remote TCP stack(or peer):和本地TCP功能一致。
    TCP连接建立（三次握手）的表格表示：
    socket创建后的默认状态是CLOSED，从这个初始状态開始，socket经历一系列状态变迁(state transition)。

1.7 behavioral model aspect(模型的行为侧重面)
名词解释：A model aspect that emphasizes the behavior of the instances in a system, including their methods, collaborations, and state histories.
详细解释：强调系统中实例行为的模型侧重面，包括其方法、协作和状态历史记录。
1.8 binary association(二元关联)
名词解释：An association between two classes. A special case of an nary association.
详细解释：两个对象实例之间的链接（link)，本身可以拥有自己的性质或属性。例如，一个交易(Trade)是买方(Buyer)和卖方(Supplier)的关联。交易可以有产品名称、数量、价格等。这些属性属于交易自身，而非买方或卖方。因而，链接的属性是关联中两个对象的共同胜质，不属于任何一方。这一点跟多重性完全一样。
1.9 association end(关联端点)
名词解释：The endpoint of an association, which connects the association to a classifier.
详细解释：一个关联端标识实体类型上的一个端部的关联，并且可以在关联的端部存在实体类型的实例的数目。关联结束定义为关联的一部分；一个关联必须恰好有两个关联结束。导航属性允许从一个关联端导航到另一关联端。
关联结束定义包含以下信息：
关联中涉及的实体类型之一。（需要）
一个关联端多重指示实体类型的实例，可以是在关联的一端的数量。关联结束多重性的值可以为一（1），零或一（0…1）或许多（*）。关联结束的名称。（可选的）有关在关联端执行的操作的信息࿰