第一章软件体系结构概述（5分）一、软件体系结构的定义●国内普遍接受的定义：软件体系结构包括构件、连接件和约束，它是可预制和可重构的软件框架结构。

●软件体系结构= 构件+ 连接件+ 约束二、软件体系结构的优势●容易理解●重用●控制成本●可分析性第二章软件体系结构风格（10分）一、软件体系结构风格定义●软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。

An architectural style defines a family of systems in terms of a pattern ofstructural organization.●体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。

词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。

An architectural style defines a vocabulary of components and connectortypes, and a set of constraints on how they can be combined.二、常见的体系结构风格●管道和过滤器➢每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。

➢过滤器风格的连接件就像是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。

●数据抽象和面向对象组织➢数据的表示方法和它们的相应操作被封装在一个抽象数据类型或对象中。

➢这种风格的构件是对象或者说是抽象数据类型的实例。

➢对象通过函数和过程的调用来进行交互。

●基于事件的隐式调用➢构件不直接调用一个过程，而是触发或广播一个或多个事件。

➢事件的触发者并不知道哪些构件会被这些事件影响。

●分层系统➢组织成一个层次结构。

➢每一层都为上一层提供了相应的服务，并且接受下一层提供的服务。

●仓库系统➢构件：中心数据结构（仓库）和一些独立构件的集合。

➢仓库和在系统中很重要的外部构件之间的相互作用。

●过程控制环路➢源自于控制理论中的模型框架，将事务处理看成输入、加工、输出、反馈、再输入的一个持续的过程模型。

➢通过持续性的加工处理过程将输入数据转换成既定属性的“产品”。

●C2风格通过连接件绑定在一起的按照一组规则运作的并行构件网络。

●C/S风格➢基于资源不对等，且为实现共享而提出来的。

➢有三个主要组成部分：数据库服务器、客户应用程序和网络。

➢优点：✓具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。

✓对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小。

✓将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。

➢缺点：✓开发成本较高。

✓客户端程序设计复杂。

✓信息内容和形式单一。

✓用户界面风格不一，使用繁杂，不利于推广使用。

✓软件移植困难。

✓软件维护和升级困难。

✓新技术不能轻易应用。

●三层C/S风格➢优点：✓能提高系统和软件的可维护性和可扩展性。

✓具有良好的可升级性和开放性。

✓可以并行开发。

✓有效地隔离开表示层与数据层，为严格的安全管理奠定了坚实的基础。

➢缺点：✓各层间的通信效率不高。

✓设计时必须慎重考虑三层间的通信方法、通信频率及数据量。

●B/S风格（浏览器/Web服务器/数据库服务器）➢优点：✓基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。

用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。

✓提供了异种机、异种网、异种应用服务器的联机、联网、统一服务的最现实的开放性基础。

➢缺点：✓缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。

✓系统扩展能力差，安全性难以控制。

✓数据查询等响应速度上，要远远低于C/S体系结构。

✓数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用。

第三章软件需求与架构（15分）一、软件需求的概念需求是指明必须实现什么的规格说明。

它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。

二、软件需求的流程三、软件需求的分类●按层分：➢业务需求：反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。

——领域专家➢用户需求：描述用户使用产品必须要完成什么任务，怎么完成的需求。

——用户➢系统需求：从系统的角度来说明软件的需求。

——开发人员●按类分：➢功能需求：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作。

➢非功能需求：产品必须具备的属性或品质，如正确性、可靠性、性能、容错性和可扩展性等。

➢设计约束：对解决方案的一些约束说明。

四、软件需求面临的主要困难●知识技能问题●态度问题●合作关系●用户说不清楚需求●双方误解需求●开发人员写不好需求文档●用户经常变更需求五、需求工程●定义：把所有与需求直接相关的活动通称为需求工程。

●需求工程创建的第一份文档是需求陈述，用于在项目开发之初理解客户的需求。

●分类：➢需求开发：目的是通过调查与分析，获取用户需求并定义产品需求。

包括：✓需求调查（需求获取）的目的是通过各种途径获取用户的需求信息（原始材料），产生《需求陈述》。

✓需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。

常见的需求分析方法有“问答分析法”和“建模分析法”两类。

✓需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《软件需求规格说明书》。

➢需求管理：目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。

包括：✓需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。

✓需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。

✓需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。

●需求工程结构图：六、需求获取技术●获取需求的方法➢面谈（访谈）：开放式问题和封闭式问题➢问卷调查：潜在使用者太多或分布太广时➢会议（需求讨论会、重点问题讨论会、业务专题讨论会、设计专题讨论会）➢文档研究➢任务示范（观察）：通过观察可以获得第一手的资料。

➢用例与角色扮演➢原型设计（小规模试验）➢研究类似公司●需求陈述➢是一份文档，陈述用户对软件的期望和需要，并对可能的规格要求加以说明。

➢需求陈述用来明确软件的用途，它不仅要说明软件有什么用，还要在宏观层次上明确软件应具备的特性。

➢核心内容✓开发该软件的动机（愿景）是什么？✓该项目的主要涉众是谁？✓希望该软件具备哪些主要功能和特性？七、需求建模●需求模型分类：➢功能模型——如UC——见下章➢业务流程模型——如DFD✓数据流图(Data Flow Diagram, DFD)是结构化方法中用于表示系统逻辑模型的一种工具，它以图形的方式描绘数据在系统中流动和处理的过程。

➢数据建模模型——如ER✓ER建模用于对数据进行建模（概念模型）✓在ER图中包含三个图形符号，分别表示：实体（矩形）、属性（椭圆）、联系（菱形）八、编写软件需求规格说明书●需求分析的主要成果：软件需求规格说明书(Software RequirementSpecification, SRS)●要求的属性：➢正确：最重要的属性。

➢清楚：让人易读易懂，不在于文档的厚度。

➢无二义性：是指每个需求只有唯一的含义。

➢一致：指《软件需求规格说明书》中各个需求之间不会发生矛盾。

➢必要：其中的各项需求对用户而言应当都是必要的。

➢完备：指《软件需求规格说明书》中没有遗漏一些必要的需求。

➢可实现：其中各项需求对开发方而言应当都是可实现的。

➢可验证：其中的各项需求对用户方而言应当都是可验证的。

➢确定优先级：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。

●阐述“做什么”而不是“怎么做”九、需求确认●需求确认是指开发方和客户方共同对《软件需求规格说明书》进行评审，双方对需求达成共识后作出承诺。

●包含两个重要工作：➢需求评审➢需求承诺十、需求跟踪技术●需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性，确保所有的工作成果符合用户需求。

●跟踪有两种方式：➢正向跟踪。

检查《软件需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。

➢逆向跟踪。

检查设计文档、代码、测试用例等工作成果是否都能在《软件需求规格说明书》中找到出处。

●跟踪矩阵➢源跟踪矩阵（需求与需求来源）➢功能跟踪矩阵（需求与功能）➢依赖跟踪矩阵（一个需求与另一个需求）十一、需求变更控制●需求发生变更的起因主要有：➢随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。

原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。

➢市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。

●需求变更控制的目的：➢如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。

➢如果需求变更带来的坏处大于好处，那么拒绝变更。

●需求基线➢已经通过正式评审和批准的规格说明或产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制过程才能修改它。

➢是被明确和固定下来的需求集合，是项目团队需要在某一特定产品版本中实现的特征和需求集合。

第五章统一建模语言UML（20分）（Unified Modeling Language）（重点看实验1）一、用例图（Use Case Diagram）●执行者和用例之间的关联关系（Association）：一根直线来表示●执行者之间的泛化关系（Generalization）（或继承关系）用例之间的关系：●包含关系：描述在多个用例中都有的公共行为，由用例A指向用例B，表示用例A中使用了用例B中的行为或功能，包含关系是通过在依赖关系上应用<<include>>构造型（衍型）来表示的。

●扩展关系：扩展用例可以在基用例之上添加新的行为，但是基用例必须声明某些特定的“扩展点”，并且扩展用例只能在这些扩展点上扩展新的行为。

扩展关系是通过在依赖关系上应用<<extend>>构造型（衍型）来表示的。

●泛化关系：➢当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。

➢在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。

➢泛化关系一般很少使用。