中南大学软件体系结构重点Word格式.docx

中南大学软件体系结构重点Word格式.docx

《中南大学软件体系结构重点Word格式.docx》由会员分享，可在线阅读，更多相关《中南大学软件体系结构重点Word格式.docx（38页珍藏版）》请在冰豆网上搜索。

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

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

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

●基于事件的隐式调用

构件不直接调用一个过程，而是触发或播送一个或多个事件。

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

●分层系统

组织成一个层次构造。

每一层都为上一层提供了相应的效劳，并且承受下一层提供的效劳。

●仓库系统

构件：

中心数据构造〔仓库〕和一些独立构件的集合。

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

●过程控制环路

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

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

●C2风格

通过连接件绑定在一起的按照一组规那么运作的并行构件网络。

●C/S风格

基于资源不对等，且为实现共享而提出来的。

有三个主要组成局部：

数据库效劳器、客户应用程序和网络。

优点：

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

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

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

缺点：

✓开发本钱较高。

✓客户端程序设计复杂。

✓信息内容和形式单一。

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

✓软件移植困难。

✓软件维护和升级困难。

✓新技术不能轻易应用。

●三层C/S风格

✓能提高系统和软件的可维护性和可扩展性。

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

✓可以并行开发。

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

✓各层间的通信效率不高。

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

●B/S风格〔浏览器/Web效劳器/数据库效劳器〕

✓基于B/S体系构造的软件，系统安装、修改和维护全在效劳器端解决。

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

✓提供了异种机、异种网、异种应用效劳器的联机、联网、统一效劳的最现实的开放性根底。

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

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

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

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

第三章软件需求与架构〔15分〕

一、软件需求的概念

需求是指明必须实现什么的规格说明。

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

二、软件需求的流程

三、软件需求的分类

●按层分：

业务需求：

反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。

——领域专家

用户需求：

描述用户使用产品必须要完成什么任务，怎么完成的需求。

——用户

系统需求：

从系统的角度来说明软件的需求。

——开发人员

●按类分：

功能需求：

系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作。

非功能需求：

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

设计约束：

对解决方案的一些约束说明。

四、软件需求面临的主要困难

●知识技能问题

●态度问题

●合作关系

●用户说不清楚需求

●双方误解需求

●开发人员写不好需求文档

●用户经常变更需求

五、需求工程

●定义：

把所有与需求直接相关的活动通称为需求工程。

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

●分类：

需求开发：

目的是通过调查与分析，获取用户需求并定义产品需求。

包括：

✓需求调查〔需求获取〕的目的是通过各种途径获取用户的需求信息〔原始材料〕，产生?

需求陈述?

。

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

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

✓需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生?

软件需求规格说明书?

需求管理：

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

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

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

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

●需求工程构造图：

六、需求获取技术

●获取需求的方法

面谈〔访谈〕：

开放式问题和封闭式问题

问卷调查：

潜在使用者太多或分布太广时

会议〔需求讨论会、重点问题讨论会、业务专题讨论会、设计专题讨论会〕

文档研究

任务示范〔观察〕：

通过观察可以获得第一手的资料。

用例与角色扮演

原型设计〔小规模试验〕

研究类似公司

●需求陈述

是一份文档，陈述用户对软件的期望和需要，并对可能的规格要求加以说明。

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

核心内容

✓开发该软件的动机〔愿景〕是什么？

✓该工程的主要涉众是谁？

✓希望该软件具备哪些主要功能和特性？

七、需求建模

●需求模型分类：

功能模型——如UC——见下章

业务流程模型——如DFD

✓数据流图（DataFlowDiagram,DFD）是构造化方法中用于表示系统逻辑模型的一种工具，它以图形的方式描绘数据在系统中流动和处理的过程。

数据建模模型——如ER

✓ER建模用于对数据进展建模〔概念模型〕

✓在ER图中包含三个图形符号，分别表示：

实体〔矩形〕、属性〔椭圆〕、联系〔菱形〕

八、编写软件需求规格说明书

●需求分析的主要成果：

软件需求规格说明书（SoftwareRequirementSpecification,SRS）

●要求的属性：

正确：

最重要的属性。

清楚：

让人易读易懂，不在于文档的厚度。

无二义性：

是指每个需求只有唯一的含义。

一致：

指?

中各个需求之间不会发生矛盾。

必要：

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

完备：

中没有遗漏一些必要的需求。

可实现：

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

可验证：

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

确定优先级：

先做优先级高的需求，后做〔甚至放弃〕优先级低的需求，这样可以将风险降到最低。

●阐述“做什么〞而不是“怎么做〞

九、需求确认

●需求确认是指开发方和客户方共同对?

进展评审，双方对需求达成共识后作出承诺。

●包含两个重要工作：

需求评审

需求承诺

十、需求跟踪技术

●需求跟踪的目的是建立与维护“需求-设计-编程-测试〞之间的一致性，确保所有的工作成果符合用户需求。

●跟踪有两种方式：

正向跟踪。

检查?

中的每个需求是否都能在后继工作成果中找到对应点。

逆向跟踪。

检查设计文档、代码、测试用例等工作成果是否都能在?

中找到出处。

●跟踪矩阵

源跟踪矩阵〔需求与需求来源〕

功能跟踪矩阵〔需求与功能〕

依赖跟踪矩阵〔一个需求与另一个需求〕

十一、需求变更控制

●需求发生变更的起因主要有：

随着工程的进展，人们〔包括开发方和客户方〕对需求的了解越来越深入。

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

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

●需求变更控制的目的：

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

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

●需求基线

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

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

第五章统一建模语言UML〔20分〕

〔UnifiedModelingLanguage〕〔重点看实验1〕

一、用例图〔UseCaseDiagram〕

●执行者和用例之间的关联关系〔Association〕：

一根直线来表示

●执行者之间的泛化关系〔Generalization〕〔或继承关系〕

用例之间的关系：

●包含关系：

描述在多个用例中都有的公共行为，由用例A指向用例B，表示用例A中使用了用例B中的行为或功能，包含关系是通过在依赖关系上应用<

<

include>

>

构造型〔衍型〕来表示的。

●扩展关系：

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

扩展关系是通过在依赖关系上应用<

extend>

●泛化关系：

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

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

泛化关系一般很少使用。

二、状态图（StateDiagram）

用来描述一个特定对象的所有可能状态及其引起状态转移的事件。

通常用状态图来描述单个对象的行为

只有那些具有重要交互行为的类，才会使用状态图来描述。

一个状态图包括一系列对象的状态及状态之间的转换。

●组成元素：

初始状态

终止状态

状态

转移

守护条件

事件

动作

三、活动图〔ActivityDiagram〕

用来表示