软件设计规范.doc

软件设计规范.doc

《软件设计规范.doc》由会员分享，可在线阅读，更多相关《软件设计规范.doc（7页珍藏版）》请在冰点文库上搜索。

软件设计规范

第一章概述

一、前言

软件设计是把需求转化为软件系统的最重要的环节，一般会包含以下几大部分：

体系结构设计、界面设计、数据结构和算法设计、数据库设计、接口设计、安全设计等。

软件设计的优劣在根本上决定了软件系统的质量。

但是，由于各种历史原因，软件设计在开发中的重要性没有得到合理的体现。

很多软件的设计工作都是有名无实，设计文档更是五花八门，几乎完全依赖于设计人员个人的设计水平与经验。

很多设计文档几乎没有使用价值，开发人员都是直接看需求。

这样，最终软件的质量完全依赖于开发人员。

开发人员水平好，软件质量就高。

开发人员水平差，软件质量就差。

为了解决这一问题，制定一份软件设计规范，就成为最好的选择。

从目前的现状出发，本规范对软件设计过程、设计方法、设计工具以及设计要做到的程度进行了规定。

同时，特别对逻辑设计进行了详细规定，物理设计在本阶段暂不做要求。

二、适用范围

本规范适用于开发部所负责的项目，其它部门的项目可进行参考。

对于Dotnet技术类项目，必须全部符合本规范。

对于Dephi技术类项目，可以进行取舍。

对于完全新建项目，必须全部符合本规范，对于在旧系统之上进行扩展的项目，可以对本规范进行取舍，对于维护类项目，可以不按本规范进行。

由于项目的特殊原因，可以对设计过程进行取舍，但不得降低所执行设计过程的规范要求。

一旦设计过程确认后，必须严格执行设计规范。

此规范的符合，是评审通过的唯一依据。

未通过设计评审的项目，可以继续进行后续工作，但评审委员会不再对此项目的软件质量负责。

三、名词解释

逻辑设计：

这是微软对软件设计工作的一种划分方式。

是指在需求的基础上，从业务逻辑和当前用户应用环境中抽象出系统对象的组成结构、流程和各个部分相互关系，另外还要设计数据库的逻辑结构和界面的逻辑关系。

逻辑设计是将用户业务语言转化为项目组语言的关键。

在逻辑设计中的对象只是抽象的系统对象，而不是物理实现中采用的类、组件、模块和页面。

物理设计：

这是微软对软件设计工作的一种划分方式。

是指在逻辑设计的基础上，从系统的逻辑对象、数据实体和界面逻辑关系中进一步整理和细化得到的设计方案。

物理设计将确定系统采用的技术方案，平台，并明确实际开发的组件、数据库表、窗口以及页面等，并考虑到实现的可能性和最终系统的性能。

系统：

是由相互作用和相互依赖的若干组成部分结合成的、具有特定功能的有机整体。

系统具有三个基本特征。

第一，系统是由若干元素组成的；第二，这些元素相互作用、互相依赖；第三，由于元素间的相互作用，使系统作为一个整体具有特定的功能。

一个管理软件系统一般会包含界面、算法、数据库等内容。

第二章软件设计过程

一、设计阶段划分

软件设计分为架构设计、逻辑设计、物理设计三个阶段，其中逻辑设计和物理设计分别又分为系统设计和组件设计两个阶段。

组件设计分为三部分：

界面设计、业务算法设计、数据库设计。

开发部的软件使用统一的软件架构，故架构设计不是每一个项目必须要做的，在此不对架构设计进行规范。

对于在统一的软件架构中没有包含的部分，各项目组可自行增加。

软件设计过程可用下图来说明：

二、过程裁减

在项目开发过程中，可能由于各种原因需要对设计过程进行裁减。

一般情况下，对于Dotnet技术类项目，必须全部采用本过程。

对于Dephi技术类项目，可以进行取舍。

对于完全新建项目，必须全部采用本过程；对于在旧系统之上进行扩展的项目，可以不进行架构设计和物理设计；对于维护类项目，可以不采用本过程。

由于项目的特殊原因，需要违反以上原则对设计过程进行裁减时，必须在设计工作开始前得到开发部经理的认可。

第三章软件设计方法

开发部的软件设计主要使用两种设计方法：

自顶向下的设计方法和面向对象的设计方法。

对于Dephi技术类项目，在得到开发部经理同意的情况下，可以采用结构化的软件设计方法。

在个别情况特殊的项目中，可以采用自底向上的设计方法，但必须得到开发部经理的认可。

在使用面向对象的方法进行设计时，必须使用UML语言。

在设计中，应尽可能的使用设计模式，以求得最好的性价平衡。

以上两种设计方法目前都已为一种工业标准，其详细情况可参见相关资料，下面仅做一个简单介绍。

一、自顶向下的软件设计方法

自顶向下的软件设计方法从整体系统角度着重考虑设计环节，由上而下有机地将系统分化为多个子系统、再将子系统分化成多个组件，直至分化出明确的类及其公共接口，然后开始编码。

此方法在设计前需要明确需求，在设计阶段可以不断验证实现设计的可行性。

经过验证的、良好的设计可以有效管理复杂度，降低自底向上设计方法中在后期“推倒重建”的风险，能让整个开发团队同步进行，适用于总体需求明确，开发任务复杂庞大的项目。

二、面向对象的软件设计方法

面向对象的设计方法是一种工程化规范，它是一种解决软件问题的设计范式，一种抽象的范式。

使用这种设计范式，我们可以用对象来表现问题领域的实体，每个对象都有相应的状态和行为。

面向对象设计的核心思想是面向自然的设计，即通过识别和表达出系统中对象、对象间的关系、对象的状态迁移等关键因素，软件设计达到自然的、正确的描述目标系统的目的，这种自然的设计忠实反映了目标系统中的对象和他们之间的关系以及他们之间的交互过程，是自然系统到软件系统的自然的映射。

在过去的十多年里，面向对象方法对软件行业起到了极大的推动作用。

在可以预测的将来，它仍将是软件设计的主要方法。

第四章逻辑设计

一、系统设计

此处的系统设计是确指的系统级的设计，它以系统做为主要设计对象，关注系统可由哪些子系统或模块构成，这些子系统或模块之间的关系如何，系统与其它系统之间的接口有哪些，接口之间如何进行通信。

系统设计的要求如下：

1、系统如何使用公司的统一架构，在架构不满足的情况下，如何进行扩充。

2、系统可以分为几个模块，各个模块之间关系如何，模块是如何通信的。

3、每个模块的外部接口是什么，接口的参数是什么，返回值是什么。

参数与返回值必须明确定义，不能有二义性。

4、如果系统较为庞大，可将系统分为子系统。

必须明确定义各个子系统之间的关系，子系统的设计要求同系统的设计要求。

5、系统与其它系统的接口有哪些，接口的参数是什么，返回值是什么。

参数与返回值必须明确定义，不能有二义性。

6、系统设计前，必须编写软件功能规格说明书，以明确功能需求。

也可在UML中使用用例图来描述软件功能。

7、在UML中，绘制包图，用来表示子系统或模块；在包图上绘制类图，用来表示接口；绘制序列图，用来描述系统与外部系统之间、子系统之间、模块之间的通信。

8、系统级的业务流程用序列图来描述，业务规则可在序列图或类图之上用文本框进行说明。

9、系统设计中所有的交互形为只描述到接口一级。

10、在系统设计中，如果有无法使用UML进行说明的内容，可使用其它格式的文档。

但必须将相关文档与UML进行链接或嵌入。

11、系统设计中不考虑人机交互的设计。

依据统一的架构设计，公司的软件采用三层架构，即界面层、业务逻辑层、数据库层。

层的设计工作在系统设计中进行，但不可将层视为模块，层高于模块。

系统设计工作必须到模块一级，不能只做到层一级。

层的设计程度可参照模块的设计程度要求。

部分简单的系统，层有可能会和模块重合。

在这种情况下，一层即只有一个模块。

二、组件设计

组件设计在这里确指的模块级的设计，不是层级的设计。

为了方便描述，组件设计分为三个层说明。

组件是面向对象思想的最好体现，我们可以认为组件即是对象。

在组件设计中，必须遵循以下几个原则：

信息隐藏、强内聚、低耦合。

1、界面设计

在很多时候，界面设计的好坏直接影响到软件的使用情况。

架构设计的信息架构设计部分，更是与界面设计关系密切。

为了有一个良好的人机交互接口，界面设计工作必须得到高度的重视。

界面设计不只包含软件使用界面，还应包含用户使用的各种打印、导入、导出报表。

在做界面设计时，必须遵循以下几个原则：

l用户界面适合于软件的功能

l容易理解

l风格一致

l及时反馈信息

l出错处理

l合理的布局

l和谐的色彩

界面设计的要求如下：

1、用UML表述界面与人互动的所有接口，包含显示信息、输入信息、操作信息。

所有的信息必须明确无二义。

2、制作可与用户进行动态互动的具体界面，优先使用开发语言进行设计。

3、只需设计到用户接口即可，不考虑内部结构。

4、在UML中用序列图描述各个界面与应用服务接口之间的交互关系。

2、业务算法设计

在三层架构的系统中，业务逻辑在中间的业务逻辑层实现，而业务算法设计主要用来实现业务流程和业务规则，也就是我们常说的业务逻辑。

所以，业务算法设计，就是指的业务逻辑层的设计。

在企业应用软件中，最复杂、最容易发生变化的是业务逻辑层。

这一层的设计好坏，直接关系到今后软件进行维护、修改、扩展的成本。

业务算法设计的要求如下：

1、所有的模块接口必须得到实现。

2、设计必须做到类的公共方法、属性、事件等。

3、在UML中使用类图来描述业务对象。

4、必须清楚描述类的关系：

继承、聚合、组合、引用。

5、在UML中，业务流程用序列图来描述，业务规则可在序列图或类图之上用文本框进行说明。

3、数据库设计

一般来说，我们都会使用关系型数据库。

所以，以下的要求全是针对的关系型数据库。

数据库表可分为以下类型：

业务数据表：

记录业务发生的过程和结果。

如，加油流水、销售单、出库单、凭证、业务账。

基本编码表：

描述业务基本信息和编码，一般变化很慢。

如，油品、组织机构、人员。

辅助编码表：

描述属性的列表值。

如，销售类型、付款方式。

系统信息表：

存放与系统操作、业务控制有关的参数。

如，用户信息、权限、用户配置信息、成本核算方式。

累计数据表：

存放业务的当前值和累计值。

如，当前库存、当前存款、累计销售、累计支出、应收账款。

结算数据表：

存放各个时期末的结存数。

如，月末库存、月末银行存款、应收账款月结。

决策数据表：

存放各个时期内发生的统计值。

如，月销售统计、月回款统计、出入库统计。

数据库设计的要求如下：

1、数据库设计最低要求符合第三范式。

2、必须设计到表、视图、存储过程、关系。

2、表的设计必须明确字段数据类型、长度、默认值、是否非空，此类型不必是具体数据库类型。

3、存储过程必须明确参数和返回值。

4、关系必须明确增、删、改时的处理方式。

5、对于一年内记录会超出百万的数据，必须考虑性能的问题。

6、表必须有唯一明确业务的字段，此字段可以不是主键。

但应尽可能使用本字段作为主健。

此字段不允许使用自增字段。

三、接口设计

接口设计是指的系统与外部系统之间和系统各子系统、模块之间的关系的设计。

接口设计工作的好坏，直接左右着系统今后维护和扩展的难易程度，必须高度重视。

基于以上原因，特将接口设计单独说明，以强调其重要性。

接口设计要充分体现强内聚低耦合的要求，不能出现到处关联的现象。

1、系统外部接口设计

系统外部接口的设计是所有设计工作的第一步，只有通过外部接口设计，才能明确系统的外部边界。

外部接口设计要求如下：

1、明确说明系统与其它系统的数据库、应用服务、界面各个部分之间的接口。

2、明确说明每个外部接口是什么，接口的参数是什么，返回值是什么。

参数与返回值必须明确定义，不能有二义性。

3、系统不得通过已设计的外部接口以外的任何方式进行外部通信。

4、接口参数是复杂对象、字符串、文件时，必须对这些参数内部结构进行详细说明。

5、在设计外部接口时，应尽量不使用复杂类型，数字型、字符串型是首选方案。

2、系统内部接口设计

系统内部接口主要是指的子系统间、层间、模块间的接口，还会包括系统与所使用的各种硬件设备之间的通信接口。

内部接口设计要求如下：

1、内部接口主要在子系统间和层间进行设计，一般情况下不要求模块间使用独立的接口进行通信，但必须明确模块之间的关联关系。

2、明确说明每个内部接口是什么，接口的参数是什么，返回值是什么。

参数与返回值必须明确定义，不能有二义性。

3、子系统间和层间不得通过已设计的接口以外的任何方式进行通信。

4、硬件接口必须明确说明通信的方式以及使用的协议，如不是通用协议，必须详细说明协议格式。

四、安全设计

安全设计要包含以下五方面的内容：

1、用户身份验证设计

2、用户授权设计

3、数据安全设计

4、安全审核设计

5、其它特别要求的安全设计，如通信安全、设备安全、存储安全等。

第五章设计工具

开发部的逻辑设计工作统一使用软件设计软件EnterpriseArchitect进行，有关EA的详细使用方法请参照其自带的联机帮助。

在进行设计评审时，将EA内容发布为网页，打包发给各评委。

7/7