软件工程学习笔记-week7

一、软件体系结构概念

软件体系结构包括构成系统的设计元素的描述、设计元素之间的交互、设计元素的组合模式以及在这些模式中的约束。

 

软件体系结构=构件+连接件+约束

构件

构件是具有某种功能的可复用的软件结构单元，表示系统中主要的计算元素和数据存储

 

连接

连接是构件间建立和维护行为关联与信息传递的途径

 

连接件

连接件表示构件之间的交互并实现构件之间的连接

 

一般构件是软件功能设计和实现的承载体

连接件是负责完成构件之间信息交换和行为联系的专用构件

 

软件体系结构的发展

 

风格、模式和框架

体系结构风格∶用于描述某一特定应用领域中系统组织的惯用模式，反映了领域中众多系统所共有的结构和语义特性。

设计模式︰描述了软件系统设计过程中常见问题的一些解决方案，通常是从大量的成功实践中总结出来的且被广泛公认的实践和知识。

软件框架︰软件框架是由开发人员定制的应用系统的骨架，是整个或部分系统的可重用设计，由一组抽象构件和构件实例间的交互方式组成。

框架和体系结构的关系

体系结构的呈现形式是一个设计规约，而框架则是“半成品”的软件

体系结构的目的是指导软件系统的开发，而框架的目的是设计复用。

 

框架和设计模式的关系∶

框架给出的是整个应用的体系结构﹔而设计模式则给出了单一设计问题的解决方案，且可以在不同的应用程序或者框架中进行应用。

举例:一个网络游戏可以基于网易的Pomelo框架开发，这是一个基于Node.js的高性能、分布式游戏服务器框架﹔在实现某个动画功能时，可能会使用观察者模式实现自动化的通知更新。

设计模式的目标是改善代码结构，提高程序的结构质量；框架强调的是设计的重用性和系统的可扩展性，以缩短开发周期，提高开发质量。

二、软件设计原则

设计原则是系统分解和模块设计的基本标准，应用这些原则可以使代码更加灵活、易于维护和扩展。

 

抽象：是关注事物中与问题相关部分而忽略其他无关部分的一种思考方法。

封装和信息隐藏：是指每个软件单元对其他所有单元都隐藏自己的设计决策，各个单元的独特性通过其外部可见的接口来描述（应将单元接口设计得尽可能简单，并将单元对于环境的设计和要求降至最低）

模块化：是在逻辑和物理上将整个系统分解成多个更小的部分，其实质是“分而治之”，即将一个复杂问题分解成若干个简单问题，然后逐个解决。

系统分解的目标：高内聚，低耦合

内聚性：是一个模块或子系统内部的依赖程度。

如果一个模块或子系统含有许多彼此相关的元素，并且它们执行类似任务，那么其内聚性比较高;如果一个模块或子系统含有许多彼此不相关的元素，其内聚性就比较低.耦合性是两个模块或子系统之间依赖关系的强度。

如果两个模块或子系统是松散耦合的，二者相互独立，那么当其中一个发生变化时对另一个产生的影响就很小;如果两个模块或子系统是紧密耦合的，其中一个发生变化就可能对另一个产生较大影响。

层次化

分层：每一层可以访问下层，不能访问上层

         封闭结构：每一层只能访问与其相邻的下一层

         开放式结构：每一层还可以访问下面更低的层次

         层次数目不应超过7±2层

划分：系统被分解成相互对等的若干模块单元

         每个模块之间依赖较少，可以独立运行

模块单元增加了处理开销，过度分层或划分会增加复杂性。

安卓操作系统层次结构

 

复用

复用是利用某些已开发的、对建立新系统有用的软件元素来生成新的软件系统，其好处在于提高生产效率，提高软件质量。

源代码复用:对构件库中的源代码构件进行复用

软件体系结构复用:对已有的软件体系结构进行复用

框架复用:对特定领域中存在的一个公共体系结构及其构件进行复用·设计模式∶通过为对象协作提供思想和范例来强调方法的复用

三、软件体系结构风格

软件体系结构风格是描述特定系统组织方式的惯用范例，强调了软件系统中通用的组织结构

常见的体系结构风格

 

面向对象风格

 

管道-过滤器风格

 

仓库体系结构

是一种以数据为中心的体系结构，适合于数据由一个模块产生而由其他模块使用的情形

层次结构

 

客户机/服务器结构

是一种分布式系统模型，作为服务器的子系统为其他客户机的子系统提供服务，作为客户机的子系统负责与用户的交互

四、软件设计过程

软件设计元素

 

系统总体设计

 

是在需求分析的基础上定义系统的设计目标，将整个系统划分成若干个子系统或模块，建立整个系统的体系结构并选择合适的系统设计策略。

系统设计目标

性能准则：

响应时间：系统响应用户请求的时间

吞吐量：在一个固定时间内系统完成的任务量

存储量：系统运行需要的存储空间

可靠性准则:

健壮性:系统承受用户无效输入的能力

可靠性:指定操作与所观察行为之间的差别

可用性:系统用于完成正常任务的时间

容错性:在错误条件下系统的运行能力

安全性:系统抵御恶意攻击的能力

预防性:在出现错误和故障时系统避免威胁人类生命的能力

维护准则:

可扩展性:增加系统功能或新类的难易程度

可修改性 :更改系统功能的难易程度

适应性 :将系统应用到不同应 用域的难易程度

可移植性:系统移植到不同平台的难易程度

可读性 :通过阅读代码理解系统的难易程度

需求可追踪性 :将代码映射到特定需求的难 易程度

最终用户准则:

效用:系统对用户工作的支持程度

易用性:用户使用系统的难易程度

成本准则:

开发成本:开发初始系统的成本

部署成本:安装系统和培训用户的成本

升级成本:从原有系统导出数据的成本

维护成本:修复错误和增强系统的成本

管理成本:对系统进行管理的成本

说明:

设计目标定义了系统应该重点考虑的质量要求

性能、可靠性和最终用户准则通常可以从非功能需求或应用领域中推断出来,维护

和成本准则需要由用户和开发人员识别。

确定子系统或模块

系统部署方案是描述系统运行期间构件和硬件节点之间的关系，在系统设计阶段处理软件/硬件的映射问题，可能会增加新的子系统或模块的定义。

定义设计策略

设计全局控制流:

控制流是系统中动作的先后次序。控制流问题需要在设计阶段考虑,其决策取决于操作者或随时间推移所产生的外部事件。

控制流机制:

过程驱动 :在需要来自参与者的数据时,操作等待输入。

事件驱动:主循环等待外部事件,在外部事件到达时,系统根据与事件相关的信息将其分配给适当的对象。

线程:系统创建任意数目的线程,每个线程对应不同的事件。如果某个线程需要额外的数据,就等待参与者的输入。

识别边界条件:

系统何时启动、初始化、关闭?

如何处理主要故障(如软件错误、断电、断网等)?

边界用例:

系统管理:对于不在普通用例中创建或销毁的对象,增加一一个系统管理员调用的用例进行管理。

启动与关闭:启动、关闭和配置构件。

异常处理:通过对需求获取中识别的一般用例进行扩展而得到,需要考虑用户错误、硬件故障、软件故障等因素。

五、Web系统架构设计

HTTP服务器

 

 

 

六、数据库选择策略