中南大学软件体系结构重点.docx
《中南大学软件体系结构重点.docx》由会员分享，可在线阅读，更多相关《中南大学软件体系结构重点.docx（38页珍藏版）》请在冰豆网上搜索。
中南大学软件体系结构重点
第一章软件体系结构概述（5分）
一、软件体系结构的定义
国内普遍接受的定义：
软件体系结构包括构件、连接件和约束，它是可预制和可重构的软件框架结构。
软件体系结构=构件+连接件+约束
二、软件体系结构的优势
容易理解
重用
控制成本
可分析性
第二章软件体系结构风格（10分）
一、软件体系结构风格定义
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。
Anarchitecturalstyledefinesafamilyofsystemsintermsofapatternofstructuralorganization.
体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。
词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
Anarchitecturalstyledefinesavocabularyofcomponentsandconnectortypes,andasetofconstraintsonhowtheycanbecombined.
二、常见的体系结构风格
管道和过滤器
每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。
过滤器风格的连接件就像是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。
数据抽象和面向对象组织
数据的表示方法和它们的相应操作被封装在一个抽象数据类型或对象中。
这种风格的构件是对象或者说是抽象数据类型的实例。
对象通过函数和过程的调用来进行交互。
基于事件的隐式调用
构件不直接调用一个过程，而是触发或广播一个或多个事件。
事件的触发者并不知道哪些构件会被这些事件影响。
分层系统
组织成一个层次结构。
每一层都为上一层提供了相应的服务，并且接受下一层提供的服务。
仓库系统
构件：
中心数据结构（仓库）和一些独立构件的集合。
仓库和在系统中很重要的外部构件之间的相互作用。
过程控制环路
源自于控制理论中的模型框架，将事务处理看成输入、加工、输出、反馈、再输入的一个持续的过程模型。
通过持续性的加工处理过程将输入数据转换成既定属性的“产品”。
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中的行为或功能，包含关系是通过在依赖关系上应用<>构造型（衍型）来表示的。
扩展关系：
扩展用例可以在基用例之上添加新的行为，但是基用例必须声明某些特定的“扩展点”，并且扩展用例只能在这些扩展点上扩展新的行为。
扩展关系是通过在依赖关系上应用<>构造型（衍型）来表示的。
泛化关系：
当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。
在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。
泛化关系一般很少使用。
二、状态图（StateDiagram）
定义：
用来描述一个特定对象的所有可能状态及其引起状态转移的事件。
通常用状态图来描述单个对象的行为
只有那些具有重要交互行为的类，才会使用状态图来描述。
一个状态图包括一系列对象的状态及状态之间的转换。
组成元素：
初始状态
终止状态
状态
转移
守护条件
事件
动作
三、活动图（ActivityDiagram）
定义：
用来表示系统中各种活动的次序，它的应用非常广泛，既可用来描述用例的工作流程，也可以用来描述类中某个方法的操作行为。
作用：
描述业务流程
描述用例路径
描述方法执行流程（程序流程图）
组成元素：
起始活动（StartActivity）
终止活动（EndActivity）
活动（Activity）
转移（Transition）或流（Flow）
决策（Decision）
守护条件（Condition）
同步条（Synchronization）
泳道（Swimlane）
四、顺序图
定义：
用于确认和丰富一个使用情境的逻辑。
将交互关系表现为一个二维图，纵向是时间轴，时间沿竖线向下延伸。
横向轴代表了在协作中各独立对象的类元角色，类元角色的活动用生命线表示。
组成元素：
生命线：
用一条纵向虚线表示。
对象：
表示为一个矩形，其中对象名称标有下划线。
激活：
是过程的执行，包括等待过程执行的时间。
激活部分替换生命线，使用长条的矩形表示。
消息：
对象之间的通信
调用消息：
对应于激活，表示它将会激活一个对象。
发送消息：
没有对应激活框，表示它不是一个调用消息，不会引发其他对象的活动。
返回消息
自身消息
创建消息
销毁消息
同步消息
异步消息
交互片段：
一个复杂的顺序图可以划分为几个小块，每一个小块称为一个交互片段。
alt:
多条路径，条件为真时执行。
opt:
任选，仅当条件为真时执行。
par:
并行，每一片段都并发执行。
loop:
循环，片段可多次执行。
critical:
临界区，只能有一个线程对它立即执行。
五、类图
类之间的关系：
关联关系（Association）
用于表示一类对象与另一类对象之间有联系
用实线连接有关联的对象所对应的类
通常将一个类的对象作为另一个类的属性
自关联
一些类的属性对象类型为该类本身
多重性关联
表示一个类的对象与另一个类的对象连接的个数。
聚合关系（Aggregation）
表示一个整体与部分的关系。
成员类是整体类的一部分，即成员对象是整体对象的一部分，但是成员对象可以脱离整体对象独立存在。
在UML中，聚合关系用带空心菱形的直线表示。
组合关系（Composition）
部分和整体具有统一的生存期。
部分对象与整体对象之间具有同生共死的关系。
整体类可以控制成员类的生命周期，即成员类的存在依赖于整体类。
在UML中，组合关系用带实心菱形的直线表示。
依赖关系（Dependency）
使用关系。
体现在某个类的方法使用另一个类的对象作为参数。
在UML中，依赖关系用带箭头的虚线表示。
泛化关系（Generalization）
用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。
在UML中，泛化关系用带空心三角形的直线来表示。
接口与实现关系（Realization）
类实现了接口，类中的操作实现了接口中所声明的操作。
在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。
六、包图
定义
一种把元素组织到一起的通用机制
用于描述包与包之间的关系
包的图标是一个带标签的文件夹。
包之间的关系
引入关系：
一个包中的类可以被另一个指定包（以及嵌套于其中的那些包）中的类引用。
在依赖线上增加一个<>衍型。
泛化关系：
表示一个包继承了另一个包的内容，同时又补充自己增加的内容。
嵌套关系：
一个包中可以包含若干个子包，构成了包的嵌套层次结构。
七、组件图（ComponentDiagram）
定义：
显示编译、链接或执行时组件之间的依赖关系，以及组件的接口和调用关系。
组件就是一个实际文件，可以有以下几种类型：
源代码组件：
一个源代码文件或者与一个包对应的若干个源代码文件。
二进制组件：
一个目标码文件，一个静态的或者动态的库文件。
可执行组件：
在一台处理器上可运行的一个可执行的程序单位，即所谓可执行程序。
组件间关系：
泛化关系、依赖关系
组成元素：
组件：
系统中可以替换的部分，一般对应一个实际文件，如exe、jar、dll等文件，它遵循并提供了一组接口的实现。
接口：
一组操作的集合，它指明了由类或组件所请求或者所提供的服务。
部件：
组件的局部实现。
端口：
被封装的组件与外界的交互点，遵循指定接口的组件通过它来收发消息。
连接件：
在特定语境下组件中两个部件之间或者两个端口之间的通信关系。
供（Provided）接口与需（Required）接口
八、部署图（DeploymentDiagram）
定义：
描述系统硬件的物理拓扑结构及在此结构上执行的软件。
显示了系统的硬件和安装在硬件上的软件，以及用于连接异构计算机之间的中间件。
组成元素：
节点和连接：
节点（Node）代表一个物理设备。
在UML中，使用一个立方体表示一个节点。
节点之间的连线表示系统之间进行交互的通信路径，在UML中被称为连接。
组件：
在部署图中，组件代表可执行的物理代码模块，如一个可执行程序，逻辑上它可以与类或包对应。
九、对象图
定义：
对象图是类图在某一时刻的一个实例。
一十、组合结构图
定义：
将每一个类放在一个整体中，从类的内部结构来审视一个类。
组合结构图可用于表示一个类的内部结构。
组成元素：
部件（Part）：
表示被描述事物所拥有的内部成分。
连接件（Connector）：
表示部件之间的关系。
端口（Port）：
表示部件和外部环境的交互点。
一十一、通信图
定义：
通信图强调参与一个交互对象的组织。
它与顺序图是同构图，也就是它们包含了相同的信息，只是表达方式不同而已，通信图与顺序图可以相互转换。
当对象及其连接有利于理解交互时，选择通信图；当只需了解交互的次序时，选择顺序图。
组成元素：
执行者（Actor）、对象（Object）、连接（Link，也称为链）、消息（Message）和守护条件（Condition）。
一十二、定时图
定义：
采用一种带数字刻度的时间轴来精确地描述消息的顺序
可视化地表示每条生命线的状态变化
可以把状态发生变化的时刻以及各个状态所持续的时间具体地表示出来。
一十三、交互概览图
定义：
交互图与活动图的混合物，可以把交互概览图理解为细化的活动图，在其中的活动都通过一些小型的顺序图来表示；也可以将其理解为利用标明控制流的活动图分解过的顺序图。
用于将一些零散的顺序图组织在一起，它采用了活动图的构造方式，利用了活动图的各种控制节点，并把活动图的每个活动结点替换为一个交互或者交互使用。
每个交互或者交互使用都使用一个顺序图表示。
面向对象设计原则
1、单一职责原则（SingleResponsibilityPrinciple,SRP）
定义：
一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。
Everyobjectshouldhaveasingleresponsibility,andthatresponsibilityshouldbeentirelyencapsulatedbytheclass.
2、开闭原则（Open-ClosedPrinciple,OCP）
定义：
一个软件实体应当对扩展开放，对修改关闭。
Softwareentitiesshouldbeopenforextension,butclosedformodification.
3、里氏代换原则（LiskovSubstitutionPrinciple,LSP）
定义：
所有引用基类（父类）的地方必须能透明地使用其子类的对象。
Functionsthatusepointersorreferencestobaseclassesmustbeabletouseobjectsofderivedclasseswithoutknowingit.
4、依赖倒转原则（DependenceInversionPrinciple,DIP）
定义：
高层模块不应该依赖低层模块，它们都应该依赖抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。
Highlevelmodulesshouldnotdependuponlowlevelmodules,bothshoulddependuponabstractions.Abstractionsshouldnotdependupondetails,detailsshoulddependuponabstractions.
5、接口隔离原则（InterfaceSegregationPrinciple,ISP）
定义：
客户端不应该依赖那些它不需要的接口。
Clientsshouldnotbeforcedtodependuponinterfacesthattheydonotuse.
6、合成复用原则（CompositeReusePrinciple,CRP）
定义：
尽量使用对象组合，而不是继承来达到复用的目的。
Favorcompositionofobjectsoverinheritanceasareusemechanism.
7、迪米特法则（LawofDemeter,LoD）
定义：
一个软件实体应当尽可能少的与其他实体发生相互作用。
设计模式
（重点看实验2、3）
一、创建型模式
简单工厂模式（SimpleFactory）
定义：
根据参数的不同返回不同类的实例，专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
优点：
实现了对责任的分割，它提供了专门的工厂类用于创建对象。
客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可。
通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。
缺点：
工厂类集中了所有产品创建逻辑，职责过重，不符合单一职责原则。
增加系统中类的个数。
系统扩展困难，不符合开闭原则。
由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。
适用范围：
工厂类负责创建的对象比较少。
客户端只知道传入工厂类的参数，对于如何创建对象不关心。
工厂方法模式（FactoryMethodPattern）
定义：
升级会员 