软件工程期末复习笔记一．基本概念1.什么是软件工程？答：见作业2.什么是参与者，角色？答：所有参与到软件项目中的人员称为参与者。

把项目或系统的一组职责称为角色。

一个角色与一组任务联系在一起，且被派给一个参与者。

一个参与者能充当多个角色。

3.系统和模型。

系统指内部关联部分的集合。

模型指系统的任何抽象。

4.软件工程开发活动：开发活动通过构造和验证应用域模型或系统模型处理复杂性问题，开发活动包括：需求获取、分析、系统设计、对象设计、实现、测试。

二.基本概念（2）1.系统开发的主要内容集中在系统的3个不同模型上：功能模型，在MUL中，使用用例图表示功能模型，以从用户观点描述系统功能。

对象模型，在MUL中，使用类图表示对象模型，使用对象、属性、关联和操作来描述系统的结构。

动态模型，在UML中，使用交互图、状态图和活动图表示动态模型，以描述系统的内部行为。

2.用例模型（功能模型）2.1用例模型=用例文档+用例图2.2用例间的关系：用例之间的关系关联（association ）、包含(include)、扩展(extend)和泛化(generalization)这几种关系。

关系关联（association ）：通信1.表示参与者用例之间进行通信。

2.不同的参与者可以访问相同的用例。

包含(include)：把它所包含的用例行为作为自身行为的一部分。

扩展(extend)：扩展用例被定义为基础用例的增量扩展。

基础用例提供扩展点以添加新的行为。

扩展用例提供插入片段以插入到基础用例的扩展点上泛化(generalization)：继承2.3 用例文档包括的内容：1.用例名。

2.范围。

3.级别。

4.主要参与者。

5.涉众及其关注点。

6.前臵条件7.后臵条件8.主事件流9.备用事件流。

3.类图（对象模型）3.1类是面向对象系统组织结构的核心。

对一组具有相同属性、操作、关系和语义的对象的抽象。

包括名称部分（Name）、属性部分（Attribute）和操作部分（Operation）。

3.2类之间的关系 1.依赖关系2.泛化关系3.关联关系4.实现关系1.依赖关系表示两个或多个模型元素之间语义上的关系。

例如：客户以某种形式依赖于提供者。

关联、实现和泛化都是依赖关系。

2.泛化关系描述了一种“is a kind of”的关系。

3.关联关系包括：名称（Name）角色（Role）多重性（Multiplicity）一对一，一对多，多对多。

聚合关系（Aggregation）（一个类由多个类组成，has a关系）组合关系（Composition）聚合关系中的一种特殊情况，是更强形式的聚合，又称强聚合。

成员对象的生命周期取决于聚合的生命周期。

聚合不仅控制着成员对象的行为，而且控制着成员对象的创建和解构导航性（Navigation）4.实现关系4.时序图（同一个用例中的变迁）表示单一用例间的一组对象之间的交互强调消息时间顺序的交互图。

时序图描述了对象之间传送消息的时间顺序，用来表示用例中的行为顺序。

5.状态图状态图表示了单一对象（或者是一组连接非常紧密的对象）的行为。

，是一个对象的状态的变迁。

三．项目组织和沟通1.一个项目的沟通涉及计划内沟通和计划外沟通，其中计划内沟通包括：1问题检查。

2现状通报会议。

3通报情况会议。

4客户和项目检查。

5发布。

计划外沟通包括：1澄清需求（需求澄清是指澄清有关任何使得系统看上去存在二义性的内容）2变化需求。

（需求变化指参与者报告问题或者是提出解决方案。

）3问题解决。

（提出问题，找到问题解决方案评审并上报后，选择一个解决方案，并进行必要的沟通和实现。

）四．需求获取1.需求工程的目标是定义所构造系统的需求。

需求工程包括两个主要活动：第一，需求获取，导出用户可理解的系统规格说明；第二，分析，其结论是给出开发者无二义理解的模型2.需求获取需求获取包括以下活动：●标识参与者标识出未来系统将支持的不同用户类型。

（自然人，软/硬件实体）●标识场景对未来系统的典型功能用一组带有细节的场景来描述。

（使用某一功能的具体过程）●标识用例从场景中抽象出用例。

●求精用例细化每一个用例和描述面临错误和异常条件时系统行为。

●标识用例之间关系标识出用例之间的依赖关系。

●标识初始分析对象建立用例的术语表●标识非功能性需求如：性能上约束、文档、资源、安全性、质量等。

3.绿地工程没有现存系统存在，开发过程从草稿开始，需求从用户和客户出提取。

再工程对一个现存系统的再设计和再实现。

界面工程对一个现存系统的用户界面的再设计。

五．分析（建模）1.分析关注系统模型的产生，这一模型称为分析模型，该模型必须正确、完全、一致和可确认。

分析模型由三个独立模型构成：●通过用例和场景表示的功能模型。

●通过类和对象图表示的分析对象模型。

●通过状态图和顺序图表示的动态模型。

2.实体对象表示系统将跟踪的持久性信息。

边界对象表示参与者与系统之间的交互。

控制对象负责用例实现。

3.分析活动3.1标识实体对象3.2 标识边界对象3.3 标识控制对象3.4 使用顺序图将用例映射成对象3.5 使用CRC卡建模的对象之间的交互3.6 标识关联（类与类之间的关系）3.7 标识聚集(表示整体—部分的关系，用钻石符号，实心钻石符号表示组合聚集，部分的存在依赖于整体，空心钻石表示共享聚集，部分和整体可以独立的存在)3.8 标识属性3.9 建模单一对象状态相关的行为（方法）3.10 建模对象之间的继承关系（用空心箭头指向父类）六．系统设计：分解系统1.系统设计是将系统分析模型变换到系统设计模型。

系统设计后，得到的是一个包括子系统分解和每个策略的清晰描述模型。

2.系统设计包括活动：●标识系统目标。

开发者标识并区分应进行优化的各种系统属性的优先次序。

（可靠性。

容错性。

安全性。

可修改性）●设计初始子系统分解。

根据用例和分析模型，开发者将系统分解成一些小的部分。

●分解求精子系统以对应设计目标。

初始的分解大多不能满足所有的设计目标。

开发者必须不断分解求精，直到所有的设计目标都被满足为止。

3.耦合用于度量子系统之间的依赖程度。

内聚用于度量子系统中类之间的依赖程度。

（耦合度越小越好，内聚越大越好）。

分层将系统看成是由多个子系统按一定层次组织起来的，每一层通过使用低层子系统服务，为上一层的子系统提供服务（层是有序的）。

划分是将多个子系统组合成多个对等的实体，这些对等实体相互提供服务。

4.体系结构七．系统设计（选择设计目标）1 将子系统映射到处理器和构件，选择硬件配臵与平台2 标识并存储持久性数据2.1标识持久性数据，我们可以通过检查所有在系统关闭之后必须保存的类，来标识持久性对象。

长期储存的2.2选择存储管理策略，有三种选择来进行存储管理：●平面文件。

这种文件是由操作系统提供的存储对象。

●关系数据库。

数据按照预先定义好的模式类型存储在表中。

表中的每一列代表一个属性。

每一行代表一个属性元组值的数据项。

个别对象的属性，则用不同表中的元组来展示。

●面向对象数据库。

以对象和关联的方式来存储数据。

出了提供一个上层抽象外，面向对象数据库为开发者提供了继承和抽象类型。

3 提供访问控制，访问权限4 设计全局控制流有3种可能的控制流机制：●过程驱动的控制。

例如，一个操作需要从一个参数那里获得数据，该操作不得不等待这些数据的输入。

●事件驱动的控制。

一个主循环等待一个外部事件。

●线程。

线程是过程驱动控制的并发单元。

5 标识边界条件5.1边界条件标识决定系统如何启动，如何初始化和如何关闭，同时还需要定义在数据发生故障和网路断开等情况下，如何处理失败。

我们把负责处理这些条件的用例称为边界用例。

边界用例有哪些：●配臵。

对每一个持久性对象，我们应该检查持久性对象在哪个用例中被创建、撤销（存档）。

●启动与关闭。

对每一个构件，我们增加3个用例来启动、关闭和配臵构件。

●异常处理。

对于每一个类型的构件失败，系统如何进行反应，由开发者决定。

通过使用异常用例，对这些决定进行文档化，这些异常用例是通过对在需求过程中标识的一般用例进行扩展而得到。

5.2一般来说，一个异常是在系统执行过程中发生的一个事件或者错误。

导致异常的不同原因主要有三个：●硬件失败。

硬件老化和失败。

●操作环境改变。

如果超出了发射器范围，无线移动系统就会失去连接。

●软件失败。

异常处理是系统对异常所做出的反应机制。

八．对象设计：复用模式解决办法1.对象设计包括：●重用（Reuse），标识商业外购构件和设计模式以利用已有的解决方法。

（复用别人的额，和把自己的做好的东西为他人复用而做准备）（第八章）●服务规格说明（Server Specification），在这个过程中，精确地描述每一个类接口。

（第九章）●对象模型重构（Object Model Restructuring），改进对象设计模型，提高该模型的可读性和扩展性。

●对象模型优化（Object Model Optimization），改进对象设计模型来标识性能标准，例如系统的响应时间和存储空间利用率等。

2.说明继承，即接口继承，只继承签名，没有继承任何实现代码。

3.实现继承，子类继承基类所有成员函数和字段。

4.授权，一种可供选择的实现继承的办法，授权不干涉现存构件且会产生更健壮的代码。

5.Liskov替换准则，Liskov替换准则能够为接口的规格说明提供一个形式化的描述。

它的本质是，如果客户代码使用了由某个父类提供的方法，那么开发者就能够新增子类而不用对代码做任何改变（子类型必须能替换它们的基类型。

）6.设计模式（是开发者通过长时间地求精，从而得到的解决重复出现问题的模板化解决方案）6.1一个设计模型包括4个要素：Name（名字），用来将一个设计模式与其他设计模式区别开。

Problem description（问题描述），用来描述该设计模式适用于何种情况。

Solution（解决方案），描述了解决该问题需要的、结合在一起的类和接口的集合。

Consequences（结果），描述了将要解决设计目标的协议和可供选择的办法。

6.2设计模式中出现的不同类：●客户类（Client Class），用来访问模式。

●模式接口（Pattern Interface），模式接口是模式中对客户可见的部分。

●实现类（Implementor Class），该类实现了模式中较低层次的类。

扩展类（Extender Class），扩展类是指为了实现一个不同操作，或者是实现模式的一个扩展活动而将一个实现类特殊化。

7.常见的设计模式8.桥梁模式原理（详见作业）9.九．对象设计：说明接口（接口：操作）1 类实现者、类扩展者和类使用者●类实现者（class implementor）负责实现待实现的类。

●类使用者（class user）在其它类的实现过程中，调用由待实现类所提供的操作，这个类成为客户类。