东南大学计算机科学与工程学院软件工程期末重点总结
2021最新版《软件工程》期末考试重点背诵内容
1.什么是软件危机及其表现？答:软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
软件危机包含下述两方面的问题:如何开发软件，以满足对软件日益增长的需求;如何维护数量不断膨胀的已有软件。
表现：(1)对软件开发成本和进度的估计常常很不准确。
(2)用户对“已完成的”软件系统不满意的现象经常发生。
(3)软件产品的质量往往靠不住。
(4)软件常常是不可维护的。
(5)软件通常没有适当的文档资料。
(6)软件成本在计算机系统总成本中所占的比例逐年上升。
(7)软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。
2.什么是软件工程？答:软件工程是指导计算机软件开发和维护的一门工程学科，由需求分析、总体设计、详细设计、编码、测试、维护和演化等一系列分工明确的活动组成。
采用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
3.什么是瀑布模型方法？(有利于大型软件开发过程中人员的组织及管理)答:按照时间顺序依次进行可行性分析、项目计划、需求分析、概要设计、详细设计、编码与单元测试、集成测试、确认验证、运行与维护等几个阶段进行软件开发。
图1 瀑布模型（软件生命周期模型）4.瀑布模型方法的优缺点：其优点体现在：（1）促进软件开发的工程化。
（2）提高了软件的成功率和质量。
（3）加强了软件开发的管理过程。
（4）强调了文档的作用，保护了软件开发商的利益。
其缺点体现在：（1）瀑布模型僵化的划分阶段、缺乏灵活性，对于软件需求不明确或不准确的问题，由于其开发模型是线性的，所以瀑布模型的风险控制能力较弱。
一方面用户只有等到整个过程的后期才能见到开发成果，中间提出的变更要求很难响应。
另一方面体现在早期的错误可能要等到开发后期的测试阶段才能发现，这样会带来严重的后果。
（2）增加了软件开发的工作量，由于开发过程各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
软件工程期末复习重点
1、什么是软件工程在《计算机科学技术百科全书》中软件工程是应用计算机科学、数学及管理科学等原理，开发软件的工程。
2、软件生存周期分哪几个阶段分别简述各个阶段的任务。
答：软件生存周期有计算机系统工程、需求分析、设计、编码、测试、运行和维护6个阶段。
A 计算机系统工程的任务是确定待开发软件的总体要求和范围，以及该软件与其他计算机系统元素之间的关系，进行成本估算，做出进度安排，并进行可行性分析，即从经济、技术、法律等方面分析待开发的软件是否有可行的解决方案，并在若干个可行的解决方案中做出选择。
B 需求分析主要解决待开发软件要“做什么”的问题，确定软件的功能、性能、数据、界面等要求，生成软件需求规约。
C 软件设计只要解决待开发软件“怎么做”的问题。
软件设计通常可分为系统设计和详细设计。
系统设计的任务是设计软件系统的体系结构，包括软件系统的组成成分、各成分的功能和接口、成分间的连接和通信，同时设计全局数据结构。
详细设计的任务是设计各个组成成分的实现细节，包括局部数据结构和算法等。
D 编码阶段的任务是用某种程序设计语言，将设计的结果转换为可执行的程序代码。
E测试阶段的任务是发现并纠正软件中的错误和缺陷。
测试主要包括单元测试、集成测试、确认测试和系统测试。
F软件完成各种测试后就可交付使用，在软件运行期间，需对投入运行的软件进行维护，即可发现了软件中潜藏的错误或需要增加新的功能或使软件适应外界环境的变化等情况出现时，对软件进行修改。
3、简述各类软件过程模型的特点。
答：典型的软件过程模型有：瀑布模型、演化模型（增量模型、原型模型、螺旋模型）、喷泉模型、基于构件的开发模型和形式方法模型等。
A瀑布模型中，上一阶段的活动完成并经过评审后才能开始下一阶段的活动，其特征是：接受上一阶段活动的结果作为本阶段活动的输入；依据上一阶段活动的结果实施本阶段应完成的活动；对本阶段的活动进行评审；将本阶段活动的结果作为输出。
B 增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的增量版本，后一个版本是对前一个版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品。
软件工程重点总结（5篇）
软件工程重点总结（5篇）第一篇：软件工程重点总结软件的定义：软件是计算机系统中与硬件相互依存的另一部分，软件包括程序、数据及其相关文档的完整集合。
在结构化程序设计时代，程序的最小单位是向对象程序设计时代，程序的最小单位是类，在类中封装了相关的数据及指令代码。
软件的特性：形态特性、智能特性、开发特特性、维护特性、废弃特性、应用特性。
软件的分类：系统软件、应用软件、支撑软软件危机的表现：软件开发周期长、成本高、软件危机发生的原因：（1）缺乏软件开发的工作的计划很难制定。
（2）软件人员与用户的交流存在障碍。
（3）软件开发过程不规范，缺少方法论和规范的指导，开发人员各自为战，缺少整体的规划和配合，不重视文字资料工作，软件难以维护。
（4）随着软件规模的增大，其复杂性往往会呈指数级升高。
（5）缺少有效的软件测评手段，提高用户的软件质量差，在运行中暴露出大量的问题，轻者影响系统的正常使用，重者发生事故，甚至造成生命财产的重大损失。
首次提出“软件工程”的概念的时间是1968年。
按工程化的原则和方法组织软件开发工作是软件工程的定义：软件工程是指导软件开发和维护的工程性学科，它以计算机科学理论和其他相关学科的理论为指导，采用工程化的概念、原理、技术和方法进行软件的开发和维护，把经过时间考验而证明是正确的管理技术和当前能够得到的最好的技术方法结合起来，以较少的代价获得高质量的软件并维护它。
软件工程的目标是运用先进的软件开发技术衡量软件的质量的六个特性：功能性、可靠软件生存期的三个时期：软件定义、软件开定义时期的主要任务是解决“做什么”的问地满足用户的需要。
开发过程中的典型文档包括：软件需求规格计说明书、用户手册。
各个阶段所要完成的基本任务：问题定义与可行性研究、需求分析、软件设计、程序编码和单元测试、集成测试和系统测试、软件运行和维护。
典型的软件生存期模型包括瀑布模型、原型模型、增量模型、螺旋模型等（喷泉模型）。
瀑布模型的特点：1）阶段间具有顺序性和依赖性。
(完整版)软件工程期末考试复习总结知识点+必考题型,推荐文档
软件工程复习资料1.软件危机产生的原因(1)软件不同于硬件，它是计算机系统的逻辑部件而不是物理部件。
在写出程序代码并在计算机上试运行之前软件开发过程的进展情况较难衡量。
很难检验开发的正确性且软件开发的质量也较难评价。
因此控制软件开发过程相当困难。
此外在软件运行过程中发现错误很可能是遇到了一个在开发期间引入的但在测试阶段没有能够检测出来的错误，所以软件维护常常意味着修改原来的设计。
这样维护的费用十分惊人，客观上使得软件较难维护。
(2)软件开发的过程是多人分工合作分阶段完成的过程，参与人员之间的沟通和配合十分重要。
但是，相当多的软件开发人员对软件的开发和维护存在不少错误的观念。
在实践的过程中没有采用工程化的方法，或多或少采用了一些错误的方法和技术。
这是造成软件危机的主要原因。
(3)开发和管理人员只重视开发而轻视问题的定义，使软件产品无法满足用户的要求。
对用户的要求没有完整准确的认识就急于编写程序。
这是许多软件开发失败的另一主要原因。
事实上，许多用户在开始时并不能准确具体地叙述他们的需要。
软件人员需要做大量深入细致的调查研究工作，反复多次与用户交流信息，才能真正全面、准确、具体地了解用户的要求。
(4)软件管理技术不能满足现代软件开发的需要，没有统一的软件质量管理规范。
首先是文档缺乏一致性和完整性，从而失去管理的依据。
因为程序只是完整软件产品的一个组成部分。
一个软件产品必须由一组的配置组成，不能只重视程序而应当特别重视软件配置。
其次，由于成本估计不准确，资金分配混乱，人员组织不合理，进度安排无序，导致软件技术无法实施。
(5)在软件的开发和维护关系问题上存在错误的观念。
软件维护工作通常是在软件完成之后进行的，因此是极端艰巨复杂的工作，需要花费很大的代价。
所以做好软件的定义工作是降低软件成本，提高软件质量的关键。
如果软件人员在定义阶段没有正确、全面地理解用户要求，直到测试阶段才发现软件产品不完全符合用户的需要，这时再修改就为时已晚了。
软件工程期末复习重点
1.软件危机的介绍在计算机软件的开发和维护过程中所遇到的一系列严重问题。
2.产生软件危机的原因与软件本身特点有关：软件开发与维护的方法不正确有关：3.消除软件危机的途径4.软件生命周期由软件定义、软件开发和运行维护3个时期组成，每个时期又进一步划分成若干个阶段。
5.软件定义时期的任务是：确定软件开发工程必须完成的总目标；确定工程的可行性；导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制定工程进度表。
这个时期的工作通常又称为系统分析，由系统分析员负责完成。
软件定义时期通常进一步划分成3个阶段，即问题定义、可行性研究和需求分析。
6.开发时期具体设计和实现在前一个时期定义的软件，它通常由下述4个阶段组成：总体设计，详细设计，编码和单元测试，综合测试。
其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。
7.维护时期的主要任务是使软件持久地满足用户的需要。
8.软件生命周期每个阶段的基本任务：问题定义、可行性研究，需求分析，总体设计，详细设计，编码和单元测试，综合测试。
9.常用软件模型区别原理：(1)瀑布模型：按照传统的瀑布模型开发软件，有下述的几个特点。
a)阶段间具有顺序性和依赖性：两重含义：段的输出文档正确，后一阶段的工作才能获得正确的结果。
①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；②前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶b) 推迟实现的观点瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。
c)质量保证的观点：软件工程的基本目标是优质、高产。
为了保证所开发的软件的质量，在瀑布模型的每个阶段都应坚持两个重要做法。
每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
软件工程期末复习必备知识点
一、概念解释1.软件：是程序，数据结构和文档的集合，用于实现系统所需要的逻辑方法、过程和控制。
2.软件危机：是软件开发和维护过程中所遇到的一系列严重的问题。
3.软件周期：是从软件从定义，开发，运行维护到废弃时经历的一个漫长的时期。
4.需求分析：是发现，求精，建模，规格说明和复审的过程。
5，概要设计：通过仔细分析需求规格说明，确定完成系统的模块以及各模块之间的关系，设计出完成预定功能的模块(软件结构)，并建立借口。
详细设计：设计完成系统的模块内的算法和数据结构。
6.模块化：将软件划分成可以独立命名的且可以独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能来满足用户的需求。
信息隐藏：一个模块内包含的信息对于一个不需要这些的模块来说是不可访问的。
7.耦合：是一个软件结构内的每个模块互连程度的度量。
内聚：一个模块间各个元素之间的紧密的程度。
8.类：是对有相同数据和相同操作的一组相似对象的抽象描述。
对象：是客观世界中事物的抽象表示，其属性（状态、数据）和相关操作（行为、方法或服务）的封装体；对象之间靠消息传递相互作用。
9.消息：是对象之间相互通信的机制，是某个对象执行其操作的规格说明。
消息传递：一个对象向另一个对象发送消息时，接收消息的对象经过解释、给予响应，这种对象之间进行通信的机制成为消息传递。
10.继承：继承是子类（新类）自动的共享父类（已有类）中定义的数据的操作的机制。
子类可以继承父类的属性和操作；同时子类可以定义自己独有的属性和操作。
子类复用父类的定义，而不修改父类。
继承具有传递性。
多态性：在一个类层次中，不同对象对相同消息做出不同的响应。
11.软件重用：是指同一事物不做修改或者稍加修改就可多次重复使用，软件重用是降低软件开发成本，提高软件开发生产率和质量的有效途径。
12.软件测试：根据软件开发的规格说明和程序的内部结构而设计的一个测试用例，利用这些测试用例去运行程序以发现设计和程序错误的过程。
软件工程期末总结
软件工程期末总结软件工程期末总结今天视频看完了，可是没有总结。
还是感觉不会总结。
一想到50讲的课，怎么总结呢？开始听的时候，是真不知道从哪里下手，因为开始看的时候有种迷迷糊糊的感觉。
软件工程，我期待的一门课就这么听完了一遍。
很有些囫囵吞枣的感觉，不过收获还是很多的，至少知道了软件工程的阶段不是只有需求分析、编程和测试维护。
当然这个很早之前就知道，只是以前根本没有概念。
第一个阶段，计划阶段，要首先对用户的要求进行了解，对软件的性能等进行了解。
然后进行可行性分析研究，在各种可行性研究中，对于软件开发人员来说，技术可行性研究最重要。
之后就是需求分析阶段了，需求分析阶段也是计划阶段的最后一部分。
需求分析定义了要做什么。
把现实的需要用程序语言表达出来。
但是这一阶段并不解决怎么做。
解决怎么做的是下一个阶段——设计阶段。
设计阶段分为概要设计和详细设计。
概要设计把每个组成部分的功能都给出意义明确的模块，每个模块都和一部分需求相对应。
但是不考虑细节。
详细设计，把每个模块的功能实现详细的表示出来，为源程序的编写打下基础。
然后就是编程阶段，我们一般最初接触的就是编程，所以编程阶段比较了解，由于前期文档已经做的很详细，功能的实现数据和算法都已经清楚了，所以编程是比较简单的。
编程完了就是测试阶段了，测试阶段的费用是最多的。
测试阶段是发现错误的阶段，改错是调试阶段。
然后就是交付用户使用，及维护。
以上几点是软件工程的生命周期的六个阶段。
软件工程过程和软件工程生命周期也不能等同。
软件工程过程如下：软件规格说明：规定软件的功能及其运行的限制软件开发：产生满足规格说明的软件：软件的确认：确认软件能够完成客户提出的要求：软件演进：为满足客户的变更要求。
软件必须在使用的过程中演进。
pdca软件工程过程与软件生存期相对应。
软件规格说明对应计划阶段，软件开发对应设计、编程阶段，软件的确认对应测试调试阶段，软件演进对应运行维护阶段。
软件开发的每个过程都有相关文档，用老师们的话说叫做以文档为驱动。
软件工程期末考试重点
《软件工程》期末复习重点第一章软件工程１.什么是软件工程。
A.把系统化的、规范的、可度量的途径应用于软件开发、运行和维护的过程，也就是把工程化应用于软件中；b.研究a中提到的途径。
２. 软件工程的三要素：方法、工具和过程。
第二章软件过程１.软件生命周期分为哪几个阶段？每个阶段的基本任务是什么？a.软件定义：确定软件开发工程必须完成的总目标问题定义：要解决的问题是什么可行性研究：上阶段所确定的问题是否有可行的解决办法？需求分析：目标系统必须做什么b.软件开发：具体设计和实现在前一个时期定义的软件。
概要设计：怎样宏观地解决问题详细设计：应如何具体地实现这个系统编码和单元测试：写出正确的、易理解、易维护的程序综合测试：通过各类型测试使达到预定要求。
c.运行维护：修正错误，使软件持久地满足用户需要。
改正性维护：诊断和改正使用中的错误适应性维护：修改以适应环境变化完善性维护：根据用户的要求改进和扩充以完善预防性维护：修改以为将来的维护作准备２.常用的过程模型有哪些？各自的特点及不足。
如：瀑布模型的不足是不能适应需求的动态变更。
A.瀑布模型特点：可强迫开发人员采用规范化的方法。
严格地规定了每个阶段必须提交的文档。
要求每个阶段交出的所有产品都必须是经过验证（评审）的。
缺点：太理想化，由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。
如果需求规格与用户需求之间有差异，就会发生这种情况。
只适用于项目开始时需求已确定的情况。
B.快速原型模型特点：快速软件产品开发基本上是线性顺序进行。
降低了规格说明文档变化的可能性。
减少了后续阶段错误的可能性。
c.增量模型优点：人员分配灵活，刚开始不用投入大量人力资源。
当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。
增量能够有计划地管理技术风险。
缺点：要求构件具备开放式的体系结构。
易退化为边做边改模型，从而使软件过程的控制失去整体性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
—————————————————————————东南大学计算机科学与工程学院《软件工程》复习总结（根据张敏灵老师的英文PPT）—————————————————————————第一章软件系统的特点：1.复杂的创造很多功能实现许多不同的（往往又是矛盾的）目标包含许多组成部分不同的参与者开发流程和软件生命周期经常持续很多年2.容易发生变化客户或终端用户需求变化发现错误开发者有了很好的理解新技术出现，员工变迁软件工程的定义：1.建模软件工程师通过建模解决复杂性问题模型：系统的抽象体现，使我们可以回答系统的问题并直观理解系统2.问题求解在有限的预算和时间下，模型寻求合理的解决方案OOSE：object-oriented software engineering需求获取需求分析系统设计对象设计实现测试3.知识获取软件工程师收集数据，组织成信息，形成知识非线性过程4.原理驱动软件工程师需要了解作出决定的环境条件和做出这些决定的基本原理用来应对变化SE概念：技术、方法和工具的集合，可以在有限的时间、预算以及变化出现的情况下实现高质量的软件系统参与者和身份系统和模型生产产品（内部产品+交付产品）功能需求和非功能需求符号，方法，方法论方法论：方法的集合，解决一类问题或说明如何以及何时每个方法需要被用到本书用到的方法论：1.需求获取和分析2.系统设计和对象设计3.变化相关的活动4.配置管理SE不仅是有关开发，也关于管理开发活动：需求获取，需求分析，系统设计，对象设计，实现测试管理活动：交流，原理管理，软件配置管理，项目管理，软件生命周期第二章UML：Unified Modeling Language面向对象软件建模中出现的标准创始人：OMT (James Rumbaugh)OOSE (Ivar Jacobson)Booch (Grady Booch)用途广泛：功能模型：用例图（用户角度）对象模型：类图（对象、属性、联系、操作角度）需求分析—>分析对象模型—>应用概念系统设计—>系统设计模型—>系统接口描述对象设计—>对象设计模型—>解决方案对象的详细描述动态模型：交互图—>在一系列对象之间进行一系列消息交换来描述行为状态机图—>针对某一个对象的状态转换活动图—>针对控制和数据流描述行为用例图：描述系统功能，在需求获取和分析时使用，从外部角度来关注系统行为用例：描述系统提供的功能，产生用户可见的结果参与者：任何与系统交互的人（用户，另一个系统，系统的物理环境）参与者在系统边界外，用例在系统边界内（乃们一定要记住用例名是写在这个椭圆下面的啊T T 学长考试的时候全写在里面了！）类图：描述系统的结构类：描述具有相同结构和行为的对象集的抽象对象：在系统执行过程中被创建、修改和销毁的类的实体有状态（包括属性值和与其他对象的联系）类图的成分：类，对象，属性，操作，联系交互图：在用例中涉及的对象（参与对象），表现的就是这些对象之间发生的交互状态机图：转换包括对象未来可以转向的状态和转变条件活动图：活动：代表一系列操作执行的建模元素针对活动来描述系统行为其他活动的结束、对象的可用和外部的活动都可以出发活动的执行与流程图相似：控制流（操作发生的顺序），数据流（操作中对象的交互）用例图：《extend》代表异常或很少调用的用例，箭头指向被扩展的用例《include》代表被分离出来的用例，箭头指向使用的用例《inheritance》代表一个用例可以通过添加细节特化另一个更一般的用例，箭头指向那个一般的用例用例描述：1.用例名称2.参与者3.事件流4.进入条件5.退出条件6.特殊需求类图：表现系统的结构需求获取分析中对应用域概念建模在系统设计中对子系统建模在对象设计中说明类的详细行为和属性类：代表一种概念，封装属性和操作，每个属性有一个类型，每个操作有一个签名,只有类名是强制的信息实例/对象：实例代表一种现象，实例名有下划线，名字可以只包括类名关系也可以通过属性来刻画关系类可以用自己的操作和属性，用虚线连在关系线上聚集：共享聚集：表示一种“属于”继承，空心菱形组合聚集：更强形式的聚集，生命周期必须一致，实心菱形限制（qualification）：减少关系的复杂性继承：“是一种”的继承，通过分类简化分析模型，子类继承父类的操作和属性包：可以用UML包机制来组织子系统对象模型建立步骤：1.找到新的类2.定义名字、属性、方法3.找到类之间的关系4.标注一般的关系（has\owns,etc.）5.决定关系之间的多重性6.重审关系7.找到分类（使用继承）8.简化、重组顺序图：在分析中，优化用例描述，找到更多的对象（参与对象）在系统设计中，优化系统接口消息—>参与对象，消息是参与对象中的方法水平虚线箭头代表数据流在消息前有个*代表迭代重复发送消息，在消息前有个[布尔表达式]代表一种发送消息的条件消息指向一个对象的激活（就是对象下面的长方形）则代表创建（creation），在最后的激活上有个代表销毁，销毁可以代表一个对象有用的生命的结束状态机图：状态：满足一个对象（或系统）某种属性的一种情形转换：被事件、条件或时间触发的状态转变Action动作：不可被打断的，有转换action，内部转换action，entry/action,exit/actionActivity活动:在状态内部的可能是长时间的活动，当退出转换被调用的时候activity会被打断，用do做标签嵌套状态机：内部转换来减少复杂度活动图：是状态图的特殊形式活动图中的状态是活动（“功能”）活动结束自动跳转，不需要驱动活动图对于描述系统的工作流程非常有用活动允许对“决定”（一个菱形）和“并发性”（竖线，包括把控制流分成几个线程和同步多个活动）进行建模活动还可以被分成若干个泳道，代表这些活动是被哪个对象或子系统实现的第三章角色：定义了责任（要去做什么）责任被指定到角色身上，角色被指定到人身上任务：描述了被管理人员追踪的最小数量级的工作，包括：1.角色2.工作产品3.开始时间4.计划工期5.需要资源工作产品：可见的任务产出，交付到用户手中的叫作交付产品活动：一系列相关的任务可能会以不同的名字再次被包含到更高级的活动当中允许关注分离在活动中存在优先关系计划内沟通：问题陈述，客户评审，项目浏览，同行评审，现状浏览，集思广益，发布，事后浏览……计划外沟通：需求的澄清，需求的变化，问题求解同步沟通机制：面对面交谈，问题和正式会面，会议，同步群件异步沟通机制：电子邮件，新闻组，万维网，Lotus公司的Notes（其他重点可以看书，还是多看看中文比较好，毕竟试卷是中文....）第四章软件生命周期：需求获取，需求分析，系统设计，系统细节设计，实现，测试需求说明用自然语言，分析模型用UML功能需求：描述系统和环境之间的交互，与实现无关非功能需求：不与功能行为直接相关的方面1.可用性：必须是可测量的（网购需要的步数）2.鲁棒性（健壮性）：错误的输入，外界环境的改变…3.有效性：系统正常运行时间的比例（不要总是down机）4.性能5.可支持性限制（伪需求Pseudo requirements）：由客户或环境提出需求确认：1.正确性：是否代表了客户的本意2.完整性：系统能应用的场景是否全面3.相容性：没有相互矛盾的需求4.明确性：需求只能有一种解释方式5.可实现性：需求能够被实现和交付6.可追踪性：每个系统行为都可以追踪到一系列的功能需求需求获取的不同方式：1.绿地工程：需求从用户和客户处抽取2.再工程：新需求从现存系统中抽取3.界面工程：需求从技术使能者或新的市场需求抽取场景：一种陈述性描述，所描述的是，在人们使用计算机系统和应用的时候他们所做的和所经历的。
（这是根据老师PPT上的原句翻译的，个人认为书上99面的翻译是错的。
原句是：”A narrative description of what people do and experience as they try to make use of computer systems and applications.”）As-is 场景：描述了当前情况，常用于再工程项目，通过观察用户并将他们的活动描述成场景，一次来理解当前系统Visionary空场景：描述了未来的系统，常用于绿地工程和再工程项目。
开发者和用户两个方面。
关于用例的在前面已经有了，再稍作补充：用例是场景的抽象提取用例可以被多个对象使用分析的关键：从用例出发，找到参与对象第五章对象建模的步骤：1.类定义2.寻找属性3.寻找方法4.寻找类之间的关系实体对象：代表被系统追踪的持久性信息（应用域对象，也被称作“业务对象”）边界对象：代表用户和系统之间的交互控制对象：代表系统所执行的控制任务不同的对象类型让我们更好的应对变化对象类型起源于Smalltalk(Alan Kay):Model, View, Controller (MVC)Model <-> Entity ObjectView <-> Boundary ObjectController <-> Control Object版型机制，模板机制（stereotype mechanism）：在UML中可以引入新的建模元素类型《String》Name还可以用图标(icons)和图形符号来定义模板在用例中寻找参与对象：1.选中一个用例，观察事件流2.做语法分析（Abbott’s Technique），名词就是对象或类的候选项，动词就是操作的候选项3.定义不同对象的类型注意：这只是在用例中寻找对象，如果是整个对象定义过程，则是如下：1.从用户和应用域专家处获得一系列场景2.从场景中抽取出用例3.再进行上面“用例中寻找参与对象”的过程，同时还要进行的是组建UML类图组建类图的过程：1.类定义（语法分析，领域专家）2.属性和操作的定义（有时在类之前就被发现）3.类关系的定义4.多重性的定义5.任务的定义6.继承的定义动态图为对象模型发现和补充操作顺序图：布局：第一列——初始化用例的参与者第二列——边界对象第三列：管理剩余用例的操作对象创建：边界对象在用力初始化的时候被创建，控制对象由边界对象创建访问：实体对象被控制对象和边界对象访问，实体对象决不能调用边界对象和控制对象构建顺序图中，可能会有新出现的事件，这些事件可以被认为是接受这个事件的类的一个public权限的操作集中控制式结构，操作可以交换顺序，有新需求时可以插入新操作非集中式控制结构，操作之间有很强的联系和顺序性UML状态图符号（Notation）事件是斜体，条件用[]括起，动作和活动之前都要加/Notation是根据Harel的工作基础上建立起来的超状态：其中有很多嵌套子状态从其他状态进入超状态是进入的第一个子状态从超状态的任意一个子状态都可以离开两种类型的并发性：系统并发性：对象并发性：导航路线：状态图可以被用作用户接口的设计状态：界面名称活动/动作：在界面名下面，前面有个“·”，一般只有退出动作会写出来状态转换：退出动作的结果（点击按钮、选择菜单、光标移动）Model verification检验模型之间转换model validation把模型结合实际进行比较（更高一层），正确性、完整性、一致性、无歧义性、可实现性对象模型占主要：系统有很多类，这些类的状态无关紧要，但是类之间的关系很复杂动态模型占主要：模型有很多事件：输入、输出、异常、错误等功能模型占主要：模型执行复杂的转换（计算包含许多步）RAD (Requirement Analysis Document)第六章“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.”- C.A.R. Hoare设计目标是对不同利益关注者的权衡子系统：在UML中以包的形式出现对象模型中的对象和类是子系统的“种子”服务：功能模型中的用例是服务的“种子”服务在系统设计中被定义子系统接口：是服务的优化，需要被很好的设计并很小子系统接口在对象设计中被定义Application programmer’s interface (API) ：APIs 在实现中定义层次：一个子系统向另一个子系统提供服务某个层次只依赖于它下层的服务，并且对它的上层一无所知UML中，Depend on 用实线，calls用虚线划分：一个层次可以水平的被分为独立的子系统，即划分同一层的划分之间可以互相提供服务划分是低耦合的子系统P2P关系虚拟机：上下层之间是一种“提供服务”的关系（关于子系统）封闭架构（模糊）：上层只能向其下一层调用操作可维护性，灵活性开放结构（透明）：每个虚拟机可以向任何一个下层的虚拟机调用操作运行效率一致性：测量一个子系统中各个类之间的依赖程度（高）耦合性：测量各个子系统之间的依赖程度（低）体系结构风格：子系统分解的模式客户端/服务器：一个或多个服务器向称谓客户端的子系统实例提供服务客户端知道服务器端的接口服务器端不知道客户端的接口常用于数据库缺点：不能满足P2P的要求P2P：ISO = International Standard OrganizationOSI = Open System Interconnection仓库(repository)：子系统访问和修改单一的数据结构子系统之间相互独立，子系统之间交互需要通过仓库完成MVC第七章UML构件图：编译时间下子系统之间的设计依赖关系UML部署图：描述系统的执行时间配置文件系统：数据只由一个人写由很多人读数据库：数据被并发的人读和写访问矩阵：每一行代表系统的参与者，每一列代表希望控制的类访问表：参与者，类，操作访问控制表：参与者，操作（针对于某个类）能力：类，操作（针对于某个参与者）第八章对象设计：对需求分析进行补充并作出实现决定应用对象：与系统相关的对象（应用域专家和终端用户定义）求解对象：与应用域没有对应（开发人员定义）继承：用新的操作或重新操作来扩展基类1.描述分类：需求分析中使用2.接口定义：对象设计中使用，定义所有对象的签名实现继承（类继承）：父类的操作已经被实现定义继承（子类型化）：只是继承被声明的操作，并不实现类库：被动的，不影响控制流框架：主动的，影响控制流授权：抓取一个操作发送到另一个对象上组合模式：模型动态聚集适配器模式：与已经存在的系统关联桥模式：与已经存在的和未来的系统关联，用于多重实现facade模式：与子系统关联英文全称：UML：unified modeling language（考到）OMT:object modeling technologyOCL（Object Constraint Language）（考到）OOAD（Object Oriented Analysis And Design)（考到）FRIEND: First Responder Interactive EmergencyNavigational DatabaseODD：The Object Design DocumentCMM：Capability Maturity Model for SoftwareLOC：length of code (代码行)COCOMO：constructive cost modelApplication programmer’s interface (API)ISO ： International Standard OrganizationOSI ： Open System Interconnection （当时写下来觉得没什么用，没想到居然真的考到这个了！）OOSE：object-oriented software engineeringRAD ：Requirement Analysis Document“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.”- C.A.R. HoareOMT (James Rumbaugh)OOSE (Ivar Jacobson)Booch (Grady Booch)—————————————————————————复(yu)习到后面几章的时候离考试已经没几个消失了，所以写下来的东西就很少了。