软件系统设计

Posted 左直拳

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了软件系统设计相关的知识,希望对你有一定的参考价值。

包括概要设计和详细设计。

一、概述

系统设计师系统分析的延伸与拓展。系统分析阶段解决“做什么”的问题,而系统设计阶段解决"怎么做"的问题。

系统设计阶段又称为物理设计阶段,任务是根据系统规格说明书中规定的功能要求,考虑实际条件,具体设计实现逻辑模型的技术方案,即设计新系统的物理模型。相对地,系统分析确定系统的基本目标和逻辑模型,因此又称为逻辑设计阶段。

实际上,系统分析与系统设计之间,还有一个阶段,就是系统架构设计。系统设计解决的是系统业务逻辑本身的物理设计问题,但业务逻辑不是运行在空中楼阁,它需要实实在在的支撑。架构设计就是负责提供这个支撑。比如说,同样处理这些业务,我们既可以采用单体架构,也可以采取SOA或者微服务架构;既可以是CS,也可以是BS,就看怎么衡量。

系统设计的内容包括概要设计和详细设计。

二、概要设计

又称为系统总体结构设计,系统开发过程中关键的一步。主要任务是将系统的功能需求分配给软件模块,确定每个模块的功能和调用关系,形成软件的模块结构图,即系统结构图。

三、详细设计

在概要设计中,将系统开发的总任务分解成许多基本的、具体的任务,为每个具体任务选择适当的技术手段和处理方法的过程称为详细设计。根据任务的不同,详细设计又可细分为:

1、网络设计
1)根据系统的要求选择网络结构,按照系统结构的划分,安排网络和设备的分布
2)根据物理位置考虑网络布线和设备的部署
3)根据实际的要求划定个网络节点的权限、级别和管理方式等
4)选择相应的系统软件和管理软件

2、代码设计
这里说的代码,不是指程序代码,而是指类似订单号这类的编号。特别提出来,作为一个设计种类,是希望确保代码(编号、编码)的唯一性、规范化和系统化。

3、输入输出设计
1)输入设计
目的确保向系统输入的数据的完整性、正确性和一致性,主要内容包括:
(1)确定输入数据的内容
(2)输入方式设计
(3)输入格式设计
(4)检验方式设计

遵循原则
(1)输入数据最少原则
(2)简单性原则。输入过程应尽量简单,既方便用户输入,节省时间,又可降低出错概率
(3)尽早验证原则。
(4)少转换原则。输入数据尽量采用原始的数据格式。

2)输出设计
目的确保输出数据的完整性、正确性和一致性,主要内容包括:
(1)确定输出的内容
(2)选择输出设备与介质
(3)确定输出格式

4、处理流程设计
不言而喻,懂的都懂。
内部执行过程,控制流,数据流。。。之类。

5、数据存储设计
选择数据存储的方式、存储介质、数据组织方式和记录格式,并估算数据的容量。主要包括:
(1)数据的统筹安排
看文件有多少,如何分布,数据是否共享,数据项存放于哪些文件。(不大好理解。)

(2)数据结构设计
其实就是数据库设计。

6、用户界面设计
黄金三原则:
1)置于用户控制之下
人机交互,允许交互的中断和撤销;允许用户定制交互方式。总之以用户为中心,用户最大。

2)减轻用户记忆负担
(1)符合用户直觉,直观
(2)快捷方式
(3)与真实世界保持一致
(4)傻瓜式操作
(5)提示及说明简洁易懂、用词准确,避免模棱两可

3)保持界面一致性

7、安全性和可靠性设计
对系统的运行环境和数据处理进行有效的控制,保证系统安全、有效地运行。

四、相关技术

(一)流程设计工具
在处理流程设计过程中,为了更清晰地表达过程规则说明,陆续出现了一些用于表示处理流程的工具,这些工具包括三类:
1)图形工具
程序流程图、IPO图、盒图、问题分析图、判定树

2)表格工具
判定表

3)语言工具
过程设计语言

1、程序流程图
Program Flow Diagram,PFD。无须多言。

2、IPO图
用IPO图对模块进行表述,用于描述每个模块的输入、输出和数据加工。

IPO图是系统设计中重要的文档资料之一,主体是处理过程说明,这个说明可以用流程图、判定树、判定表、盒图、问题分析图或过程描述语言来进行描述。IPO图中的输入、输出与功能模块、文件及系统外部项则需要通过数据字典来描述,并适当添加注释。

3、N-S图(盒图)
也是一种流程图,其创作出发点是为了避免流程图在描述程序逻辑时的随意性和灵活性。由顺序、选择等5种控制结构相互组合与嵌套而成。N-S图过程作用域明确,没有箭头,不能随意转移控制,而且容易表示嵌套关系和层次关系,具有强烈的结构化特征。但是问题很复杂时,N-S图可能很大。

N、S是两个作者的名字首字母。也称为盒图。

4、问题分析图
Problem Analysis Diagram,PAD,也是一种流程图,描述详细设计的工具。由日立公司提出。PAD具有清晰的逻辑结构、标准化的图形等优点。更重要的是,它可以引导设计人员使用结构化程序设计方法,提高程序质量。

5、判定树
判定树(Decision Tree)也是用来表示逻辑判断问题的一种常用图形工具。用树来表达不同条件下的不同处理流程,比语言、表格都要直观。

6、判定表
Decision Table。表格比语言描述较为直观

7、过程设计语言
Process Design Language,PDL。也称为结构化语言或伪代码(pseudo code)。

(二)结构化设计和面向对象设计
系统设计可以分为结构化设计和面向对象设计两种方法。

结构化设计(Structured Design,SD)是一种面向数据流的方法,以需求规格说明书、系统分析阶段产生的数据流图和数据字典等文档为基础,是一个自顶向下、逐步求精和模块化的过程。

SD的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构,分为概要设计和详细设计两个阶段,其中概要设计确定软件系统的结构,对系统进行模块划分,确定每个模块的功能、接口和模块之间的调用关系;详细设计负责为每个模块设计实现的细节。

面向对象设计方法里,并没有强调结构化方法那样的阶段性,因此一般不引入概要、详细设计的概念。如果非要有这种分工的话,可以将包的划分、类及对象间的关系、类的对外属性、方法及协作设计看做概要设计;类属性、方法的内部实现看做详细设计。

1、结构化设计
在结构化设计体系里,模块是系统的基本组成单位。模块的特点是可以自由组合、分解和变换,系统中任何一个处理功能都可以看成一个模块。

【模块原则】
1)信息隐蔽与抽象
采用封装技术,隐藏细节,使模块间的接口尽量简单,利于提高模块的独立性。这跟面向对象设计中的最少知识原则(迪米特法则,不跟陌生人讲话)是相通的。

2)模块划分要注意
(1)大小要适中
每个模块应该功能单一。过大则系统分解不充分,模块复杂度大,逻辑不清;多小则模块间调用频繁,依赖严重,模块反而失去独立性。

(2)多扇入,少扇出
多扇入,即被外部调用机会多,说明模块复用性很好;少扇出,依赖下级模块数量不能太多,降低复杂度。

(3)深度和宽度适中
深度表示模块的层数,宽度则是同一个层次上的模块总数的最大值。
层数过多,是否模块过小,适当合并;宽度过大,系统太复杂。宽度和深度应适当权衡。

3)低耦合
耦合指模块间的联系程度。
低耦合使得模块间尽可能相对独立,各模块可以单独开发和维护。

4)高内聚
内聚表示模块内部各成分之间的联系程度。是从功能角度来衡量模块内的联系。
内聚高使得模块的可理解性和维护性大大加强。

【模块类型】
从上级模块(调用者)的角度来看,模块可分为以下类型:
1)传入模块
从下属模块获取数据,处理后传给上级模块。

2)传出模块
从上级模块获取数据,处理后传给下属模块。

3)变换模块
加工模块。从上级模块获取数据,处理后再传回上级模块。

4)协调模块
对所有下属模块进行协调和管理的模块。

2、面向对象设计
OOD是OOA的延续。基本思想是抽象、封装和可扩展性,其中可扩展性通过继承和多态来实现。

1)类
正如结构化设计体系里,模块是系统基本组成单位一样,在面向对象设计里,类是重要组成部分。它是具有相同属性、方法和关系的对象集合的总称。设计类是OOD中最重要的工作,也最为复杂和耗时。

类分为
(1)实体类
实体类映射需求中的每个实体,保存需要持久化的信息。实体类一定有属性,但不一定有方法。

(2)控制类
控制用例工作的类,一般是由动宾结构的短语(动词 + 名词 或 名词 + 动词)进行命名。通常,控制类可以没有属性,但一定有方法。

(3)边界类
边界类用于封装在用例内、外流动的信息或数据流。边界类使参与者能与系统交互,是一种用于对系统外部环境与内部运作之间的交互建模的类,常见的边界类有窗口、通信协议、打印机接口、传感器和终端等,甚至包括产生的报表。每个参与者和用例交互至少要有一个边界类。

通常,边界类既有属性也有方法。

2)面向对象设计原则
六大原则
(1)开闭原则
(2)里氏替换原则

(3)依赖倒置原则
抽象不应该依赖于细节,细节应当依赖于抽象。即面向接口编程,而不是针对实现编程。

(4)组合/聚合原则
又称为合成复用原则。尽量使用组合/聚合关系,少用继承。

(5)接口隔离原则
使用多个专门的接口,而不是一个单一的总接口,即接口单一职责,最小化原则。

(6)最少知识原则(迪米特法则)
信息隐藏,提高类独立性,降低类之间耦合度,利于子系统间的解耦。

(三)设计模式
无须多言

以上是关于软件系统设计的主要内容,如果未能解决你的问题,请参考以下文章

软件定义网络基础---REST API的设计规范

谈谈到底什么是抽象,以及软件设计的抽象原则

RESTful 介绍

MYSQL组织结构设计构思(快速查上级和下级)

RESTful API 设计最佳实践

通俗易懂的 RESTful API 设计规范