讲授视频在线视频

软件设计

是软件开发阶段的重要步骤

它的主要任务

是在需求分析的基础上

形成软件系统的设计方案

软件交互设计

通过分析和理解用户的任务需求

对软件的人机交互 操作逻辑

和用户界面进行设计

系统总体设计

主要是关注系统的质量属性

对整个系统进行模块化的分解

并且选择合适的设计策略

模块设计和实现

则是应用良好的设计原则

进一步地细化和实现

所分解的模块单元

这里可能涉及到

数据结构设计 算法设计

和数据库设计等

系统总体设计

是整个软件设计的关键环节

在这里

我们要重点讲解

它的主要过程和任务

系统设计

首先要明确

系统应该关注的质量属性

定义系统满足的设计目标

然后按照高内聚 低耦合的原则

把整个系统进行模块化的分解

并且选择系统部署方案

把所分解的模块

映射到相应的硬件上

接下来

进一步地定义数据存储

访问控制 全局控制

等一系列的设计策略

最后通过评审活动

来进一步地改进设计质量

确保设计方案的正确性 完备性

一致性和可实现性

系统设计

是通过分解和逐步求精得到的

这里我们用一个平面规划的例子

来说明如何进行系统设计

这个住宅的住户

是一对夫妻

和一个孩子共同生活

要求有单独学习和会客的空间

住户每天行走的路程要求最短

卧室的白天采光量

要求达到最大

假设住户大部分的时间

集中在客厅/餐厅

和主卧室的区域进行活动

那么如何给出

满足上述约束的

平面规划方案

设计师根据功能使用的要求

把整个住宅

划分成两个卧室 一个书房

一个客厅/餐厅

一个厨房和一个盥洗室

这就形成了上面显示的

版本1的平面规划方案

在这个版本中

我们仔细分析可以发现

厨房和客厅/餐厅的距离太远

不方便用餐时

餐具的端进端出

所以我们把卧室2

和客厅/餐厅进行对换

而且客厅/餐厅

调整到南面也有好处

在版本2中

我们又发现厨房和楼梯

距离大门太远

所以我们把大门

移动到北边的楼梯边上

这样调整之后

可以重新定位卧室2

并把盥洗室调整到书房的旁边

使它更靠近两个卧室

同时也加大了餐厅

客厅的面积

显然

版本3的规划方案

满足了最初的所有约束条件

建筑规划设计

和软件系统的总体设计很相似

我们考虑系统的功能需求

和非功能需求

把整个系统

划分成更为简单的模块和接口

在系统设计发生变化的时候

会造成代价很高的返工

一般来说

系统的很多质量需求

尤其是非功能需求

主要是体现在

系统的总体设计方案中

而不是具体的功能模块的实现上

性能是影响系统使用的重要因素

主要考虑

响应时间 吞吐量

和存储等三个方面

由于系统的硬件资源

和服务能力是有限的

响应时间和吞吐量

不太可能同时达到最优

有时候可能以响应时间为代价

来获得更高的吞吐量

有时候又要以吞吐量为代价

来得到更好的响应时间

所以在设计的时候

需要对这两个方面进行权衡

另外也要考虑

是采用内存空间

来换取更高的速度

还是在可接受的一个速度范围内

有限度地使用内存空间

总之

在系统设计时

要综合考虑硬件资源

和业务使用的情况

来选择合适的方案

使系统的性能

达到一个可接受的程度

可靠性

涉及到系统运行时

发生崩溃的可能性

系统对可用性和容错性的支持

以及安全防范等方面的问题

在系统设计时

我们希望考虑这些因素

在设计方案上

给出可能的实现方法

比如说

对于抢票应用来说

需要考虑用什么样的方法

来防止恶意的刷票

或者非法复制电子票等情况

一种方案

是在活动介绍的页面进行处理

另一种方案

是利用微信的安全验证的机制

来保证

不同的选择

在具体实现上是不一样的

系统在投入使用之后

还要进行维护和扩展新功能

那么在系统设计时

也要考虑到

如何才能更容易地进行修改

这会涉及到代码的可读性

可修改性和可扩展性

等一系列的属性

从最终用户的角度来说

除了要考虑性能

可靠性这些因素之外

还要考虑到

是不是可以提高工作效率

或者很容易使用等方面的问题

成本也是影响系统设计方案的

一个因素

我们需要考虑开发 部署

升级和维护的成本

比如说

微信抢票应用

是校园里使用的

一个非商业目的的系统

所以它的开发

部署和维护

都要是低成本的

在设计方案上

主要是选用

那些在较低的硬件资源下的

开源框架或者平台

在系统设计时

我们会重点来考虑

几个少数的主要目标

但是这些目标

有可能是互相牵制的

例如

开发一个安全 可靠

而且廉价的系统

可能就是不现实的

在这种情况下

我们需要

优先考虑一些主要的目标

然后再把这些目标

来结合其他的目标进行权衡

这里列出了可能遇到的

几种设计目标权衡的例子

对于系统性能方面

如果响应时间和吞吐量

不能满足系统需求

就有可能使用更多的存储空间

来进行加速

如果软件受到存储空间的限制

也有可能牺牲一定的速度

对数据进行压缩处理

在开发管理方面

如果进度出现了延迟

我们可以考虑减少一定的功能

来保证按时的交付

也可以考虑

推迟交付的时间

而保证交付所有的功能

不过在互联网时代

通常及时的上线交付是更重要的

为了及时上线

我们有时候也会选择

先发布一个有少量缺陷的系统

随后再进行升级和修复

当然

赶进度也是经常发生的

加班是一个有效的方法

在项目的后期

增加人手是不可取的

系统设计的一个关键步骤

是进行模块化的分解

一般情况下

首先是按照功能进行模块的划分

在此基础上

还要把数据 硬件

时间要求很高的部分独立出来

并且把用户界面 业务逻辑

进行分离等等

确定系统结构时

可能会选择已有的体系结构风格

或者软件框架

这一部分的内容

在上一章已经进行了讲解

这里就不再进行讲述

在模块分解之后

我们可以把这些模块

通过简单的统一接口进行封装

从而减少模块之间的依赖程度

系统设计

还要考虑系统运行部署的情况

把所分解的子系统或者模块

映射到相应的硬件上

在这个过程中

也有可能会增加新的子系统

或者模块

这是一个

微信抢票应用的部署方案

后台的管理员

使用PC端的浏览器进行操作

学生使用手机微信进行操作

抢票的请求由微信的服务器

转发给应用服务器

应用服务器处理相应的

抢票的业务逻辑

数据库的服务器

处理数据的存储

根据这个部署方案

我们就可以把抢票应用的子系统

或者模块

对应到具体的硬件上

对于Web应用来说

选择合适的数据存储策略

也是非常重要的

一般来说

主要是有文件和数据库两种形式

数据库

又分成关系数据库

NoSQL数据库

和内存数据库

三种类型

关于数据库的选择策略

我们在后面有专门的一节

来进行讲述

在多用户系统中

不同角色的用户

对系统功能和数据操作

有不同的访问权限

比如说微信的抢票应用中

管理员可以创建和发布活动

任何用户都可以浏览活动的信息

但是只有校内的学生用户

才能参与抢票

在这个应用中

我们通过学号和密码

来识别用户的身份

并且调用校方的验证系统

来进行学生身份的验证

在系统设计时

还要考虑全局的控制流机制

和实现方式

一般来说

有三种可能的控制流机制

分别是过程驱动 事件驱动

和多线程

对于微信抢票应用来说

我们可以采用单线程 事件驱动

和异步任务处理

来实现整个控制流

这部分的相关内容

将在下一节进行介绍

最后还要考虑系统的启动

关闭和异常处理

等一些边界情况

并且提出具体的实现策略