二、软件设计阶段

软件设计

原因

需求分析后直接编程实现 好处/坏处？
好处： 对于中小和成熟的系统，构建速度快
坏处： 系统的性能和可维护性差，分工不合理

也就是说有以下问题未解决：

  • 相关联的功能在哪？
  • 非功能性需求在哪实现？
  • 代码修改时影响范围多大？

因此需要 软件设计 架起 写代码和需求工程 之间的桥梁。

设计是一个把问题转换成解决方案的创造性过程。

软件设计作用： 连接需求工程和软件构建

\(需求模型、需求规格说明 \to 软件设计 \to 软件系统\)
image

注意：

  • 软件设计是将需求 准确转化 为最终软件产品或系统的唯一方法，

  • 是所有软件工程活动和随后软件支持活动的基础；

  • 软件设计是质量形成的地方，并且提供了可用于质量评估的软件表示。

设计思想：分层

为了降低问题的复杂度，在设计阶段常常使用分层设计思想。

把设计阶段划分为四层，自顶向下，逐层细化，从下到上分别是：
1.数据/类的设计 2. 体系结构设计 3. 接口设计 4. 构件级设计

image

注意：

  1. 每一层，都有相对应 的需求视角和产物。
  2. 整个设计过程，是一个自顶向下，逐层细化的过程

1）数据/类设计： 为数据对象及其属性设计恰当的数据结构。

例如：建立类（不写具体属性等）

2）体系结构设计： 选择适用的体系结构风格。
将系统分割为若干个设计子系统，在体系结构内分配子系统。
创建一系列的设计类或构件。

例如：将类按照三层架构分包

3）接口设计： 设计所有外部接口、用户接口。

设计接口及其实现，找需求接口

4）构件级设计： 进行构件级设计。

对应于软件系统开发时的模块的级别

理解：和建筑设计对比

软件设计 建筑设计
数据/类设计 建筑的原材料
体系结构设计 整体结构的设计（楼的大小，楼间距离等等）
接口设计 水管电路电梯等等路线的设计（属于建筑又不属于建筑的）
构件级设计 一个房间的具体设计（房屋划分、家具放置等等）（一个房间设计完，其他房间就可以copy）

实例

功能演示：登录功能

登录系统时，需要输入用户名和密码，点击登录按钮。
image

然后需要你稍微等一会，系统会进行一些处理，几秒钟之后，你会看到系统显示出登录的结果。

那这等待的几秒钟，系统做了些什么呢？
image
这个系统内部，我们使用了B/S结构的分层架构，并且将其简化到最简的结构。系统内部分为三个子部分。

  • 用户在界面输入信息后，界面将信息传递给内部的UI层，这一层会做简单的输入验证，比如是否为空等等。不具有其他处理能力。

  • 验证完成后，UI层会将界面输入继续向后传递到BLL层，也就是业务逻辑层。在这里，用户的数据和指令将得到处理。
    比如对登录的数据，BLL层会找到相应的处理代码，进行处理。登录需要进行用户名和密码的验证，也就是一个比对，而此时需要的正确的用户名和密码，BLL层中并没有存储。

  • 因此，代码会经由DBI层，访问到数据库，去查询。并且把查询到的结果，返回给代码进行比对。

  • 最后BLL层会把比对结果返回给UI层，UI根据结果，控制界面，显示登录结果。

这样用户就看到了登录成功的页面了。

在这个演示中，存储信息的数据库，是从数据设计的视角来进行设计的，对应到第一层。
image

系统内部的功能处理单元，是从体系结构视角来设计的，
而每个单元内部的结构，是从构件设计的视角来设计的。

image

最后的界面，是从人机交互设计视角（接口设计的一部分），也就是接口设计视角来设计的。而每一个视角，都对应到软件设计的一个层。
image

软件设计过程

软件设计要怎么做？软件设计的分层
image
也就是说，软件设计的每一层，都会对应到一系列的任务。

设计过程是一个自顶向下，逐层细化的过程，采用迭代开发的流程：
流程=工作内容=活动

image

设计原则

软件设计的核心问题： 控制由于软件复杂性引起的“系统复杂度”。

软件设计解决复杂度难题的主要思路：分而治之。具体来说就是：
image

  1. 分解（decomposition）：横向上将系统分割为几个相对简单的子系统，以及各子系统之间的关系。

  2. 抽象（abstraction）：在纵向上聚焦各子系统的接口。

接口与实现：
在抽象的思想下，分解后的系统可以理解为两个部分：

  1. 内部的部分：实现
  2. 向外展示的部分：接口

接口与实现相对，是各子系统之间交流的契约，是整个系统的关键所在、本质所在。

注意： 分解和抽象是有层次性的。

软件设计方法

有两种场景的设计方法：

  1. 结构化设计
  2. 面向对象设计方法

结构化设计方法

按照功能分解系统。自顶向下，逐步求精

模型： \(数据流图 ＋过程描述 \to 结构图\)

面向对象设计方法

数据抽象、职责驱动

封装、继承、多态

依据抽象和模块化的思想，利用面向对象设计模型，表现出对象的职责分配和协作。

提高软件的可扩展性和可复用性

设计模型

  1. 数据设计模型
    为数据对象及其属性设计恰当的数据结构。

  2. 体系结构设计模型
    选择适用的体系结构风格。
    将系统分割为若干个设计子系统，在体系结构内分配子系统。
    创建一系列的设计类或构件。

  3. 接口设计模型
    设计所有外部接口、用户接口。

  4. 构件级设计模型
    进行构件级设计。

  5. 部署级设计模型
    开发部署模型。

不同模型的任务：
①数据设计视角

  • 表和表的关系

②体系结构设计视角

  • 体系结构设计

  • 功能模块分解

  • 模块内部静态结构

  • 模块间的信息互联

  • 模块间的服务支持

③构件级设计视角

  • 类的结构及关系
  • 类之间的消息通信
  • 对象内部的算法结构
  • 对象的状态转移

④用户接口设计视角
image

  • 了解交互需求

  • 整理交互信息

  • 设计交互流程

  • 建立设计规范

  • 设计交互界面原型

  • 提升用户体验

  • 进行设计评审

⑤部署级设计视角
image

软件设计的描述

《软件体系结构设计规格说明书》
《软件数据设计规格说明书》
《软件详细设计规格说明书》
《软件人机交互设计规格说明书》
image

软件体系结构设计

难度： ★★★

软件体系结构（Software Architecture）是指：
系统的一个或者多个结构，它包括软件构件、构件的外部可见属性以及它们之间的相互关系。-- [Bas03]

目的/作用

为什么需要进行体系结构设计？
软件体系结构决定软件产品的整体质量。
如果不进行顶层设计，而是直接开始细节的设计，往往会产生质量差的系统。

软件体系结构风格

每种体系结构风格描述一种系统类别，包括：

  1. 完成系统需要的某种功能的一组构件；
  2. 能使构件间实现“通信、合作和协调的”一组连接件。
  3. 定义构件如何集成为系统的约束；
  4. 语义模型，能使设计者通过分析系统组成成分的已知属性来理解系统的整体性质。

常见的软件体系结构
1）C/S结构
2）B/S结构
3）层次体系结构
4）MVC

区别几个概念

软件架构（如 SpringBoot等)
软件框架（如SSH、SSM）
软件模式（设计模式）

设计路线

1）建立体系结构环境图
2）定义体系结构原型(archetype)
原型是表示核心抽象的类或模式，该抽象对于目标系统体系结构的设计非常关键。
3）将体系结构精化为构件
将体系结构精化为构件时，系统的结构就开始显现。
4）描述系统实例，验证设计方案
开发体系结构实际用例，将体系结构应用到特定问题上，以证明结构和构件是合理的。

软件体系结构的描述

软件体系结构设计文档

使用多个视图，表述和记录体系结构的产品集合；

每个视图是从一组利益相关者关注点的角度观察的整个系统的一种表示。

软件系统逻辑架构 构建案例

体系结构集成与测试

体系结构集成与测试
集成策略
桩、驱动与集成测试用例

  1. 集成策略
    1）大爆炸式
    将所以模块一次性组合在一起。
    优点：迅速完成集成；
    确定：成功率低。
    2）增量式
    自顶向下式
    自底向上式
    三明治式
    持续集成

数据库逻辑结构设计

难度：★★☆

案例引入
YourTour系统（旅游线路预定系统）
YourTour是一个为旅行社和其目标顾客提供服务的系统。它能够将多个景点组成一条旅游线路，而且能够为所有参加线路的游客提供所需的住宿及往返长交通预定。
用例图
image

1. 实体关系建模（已经完成）

实体关系建模在 概念结构设计
实体关系图（ER图）

实体

  • 一组具有相同属性的对象。属性是实体包含的元素。
  • 是需求分析产生，经用户确认的数据集合。

关系

  • 实体之间特有的关联。
  • 关系有名称定义和数量级约束（1:1，1:n，n:m）。

案例的ER图：
注意：案例ER图中没有给出属性，ER图是要给出属性的
image

2. 数据库逻辑结构设计

任务： 把概念结构设计（ER图）转换为与选用的DBMS（数据库管理系统）产品所支持的数据模型相符合的逻辑结构（模式）。

具体来说就是：

  • 因为目前使用的数据库基本都是关系数据库；
  • 因此一般来说，就是要要将ER图转换为关系模式，并进行优化。

注意：
数据库逻辑结构设计决定了数据库及其应用的整体性能。

数据库逻辑结构设计的任务

  1. 将ER图映射为表。
    创建表、属性及关系的基本描述。

  2. 用规范化方法检查表结构（第三范式）。

  3. 验证数据表是否支持用户事务，满足业务规则约束。
    用户事务：多记录增加或删除；
    业务规则：数据、属性域约束；实体完整性；多样性；参照完整性等。

1）将ER图映射为表。

映射属性对照表：

ER图 数据库
实体 表
属性 字段
标识属性 主键(PK)
一般属性 表字段
复合/多值属性 表及关系

关系
1：1 及 1：n 关系 \(\to\)表关系

n：m 关系 \(\to\)关系表

注意：案例ER图中没有给出属性，ER图是要给出属性的
image

image
image

2）用规范化方法检查表结构（第三范式）。

检查并修改表结构，以符合第三范式（3NF）。

1NF：数据库表中的字段都是单一属性的，不可再分。
2NF：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖。
3NF：数据表中不存在非关键字段对任一候选关键字段的传递函数依赖。

3）检查数据表是否支持用户事务，满足业务规则约束。

用户事务的检查
保证数据库逻辑结构设计，能够满足用户事务在数据方面的需求。
业务规则的检查
保证数据库表对业务规则约束的支持。

作用：
在对用户事务、业务规则约束的检查过程中，优化和细化设计方案。
提高质量，符合用户需求。

用户事务

用户事务
目的：保证数据库逻辑结构设计，能够满足用户事务在数据方面的需求。

检查方法：根据用户事务的数据需求，(设计复杂用例)

  • 检查数据在一个或多个表中是否可存储；
  • 如果存储在多个表中，检查这些表是否能够通过主/外健机制连接起来。

对业务规则约束的检查

目的：保证数据库表对业务规则约束的支持。
检查项目：

  • 字段数据类型、字段长度；
  • 字段是否允许为空；
  • 字段实际意义约束。
posted @ 2022-11-01 08:53  kingwzun  阅读(430)  评论(0)  编辑  收藏  举报