oa系统的设计

申请免费试用、咨询电话：400-8352-114

 　概要设计的主要任务是把需求分析得到的系统扩展用例图转换为软件结构和数据结构。设计软件结构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等。数据结构设计包括数据特征的描述、确定数据的结构特性、以及数据库的设计。显然，概要设计建立的是目标系统的逻辑模型.

　　详细设计是软件工程中软件开发的一个步骤，就是对概要设计的一个细化，就是详细设计每个模块实现算法，所需的局部结构。在详细设计阶段，主要是通过需求分析的结果，设计出满足用户需求的嵌入式系统产品。

　　在需求明确、准备开始编码之前，要做概要设计，而详细设计可能大部分公司没有做，有做的也大部分是和编码同步进行，或者在编码之后。因此，对大部分的公司来说，概要设计文档是唯一的设计文档，对后面的开发、测试、实施、维护工作起到关键性的影响。

　　一、问题的提出

　　概要设计写什么?概要设计怎么做?

　　如何判断设计的模块是完整的?

　　为什么说设计阶段过于重视业务流程是个误区?

　　以需求分析文档还是以概要设计文档来评估开发工作量、指导开发计划准确?

　　结构化好还是面向对象好?

　　二、概要设计的目的

　　将软件系统需求转换为未来系统的设计;

　　逐步开发强壮的系统构架;

　　使设计适合于实施环境，为提高性能而进行设计;

　　结构应该被分解为模块和库。

　　三、概要设计的任务

　　制定规范：代码体系、接口规约、命名规则。这是项目小组今后共同作战的基础，有了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法，大家就有了共同的工作语言、共同的工作平台，使整个软件开发工作可以协调有序地进行。

　　总体结构设计：

　　功能(加工)->模块：每个功能用那些模块实现，保证每个功能都有相应的模块来实现;

　　模块层次结构：某个角度的软件框架视图;

　　模块间的调用关系：模块间的接口的总体描述;

　　模块间的接口：传递的信息及其结构;

　　处理方式设计：满足功能和性能的算法

　　四、概要设计写什么

　　结构化软件设计说明书结构(因篇幅有限和过时嫌疑，在此不作过多解释)

　　任务：目标、环境、需求、局限;

　　总体设计：处理流程、总体结构与模块、功能与模块的关系;

　　接口设计：总体说明外部用户、软、硬件接口;内部模块间接口(注：接口≈系统界面)

　　数据结构：逻辑结构、物理结构，与程序结构的关系;

　　模块设计：每个模块“做什么”、简要说明“怎么做”(输入、输出、处理逻辑、与其它模块的接口，与其它系统或硬件的接口)，处在什么逻辑位置、物理位置;

　　1 概述

　　系统简述、软件设计目标、参考资料、修订版本记录

　　这部分论述整个系统的设计目标，明确地说明哪些功能是系统决定实现而哪些时不准备实现的。同时，对于非功能性的需求例如性能、可用性等，亦需提及。需求规格说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。

　　这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特点和功能。在随后的文档部分，将解释设计是怎么来实现这些的。

　　2 术语表

　　对本文档中所使用的各种术语进行说明。如果一些术语在需求规格说明书中已经说明过了

　　3 用例

　　此处要求系统用用例图表述(UML)，对每个用例(正常处理的情况)要有中文叙述。

　　4 设计概述

　　4.1 简述

　　这部分要求突出整个设计所采用的方法(是面向对象设计还是结构化设计)、系统的体系结构(例如客户/服务器结构)以及使用到的相应技术和工具(例如OMT、Rose)

　　4.2 系统结构设计

　　这部分要求提供高层系统结构(顶层系统结构、各子系统结构)的描述，使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离，对前者进行描述。别忘了说明图中用到的俗语和符号。

　　4.3 系统界面

　　各种提供给用户的界面以及外部系统在此处要予以说明。如果在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，可以指引读者参考需求说明。如果系统提供了对其它系统的接口，比如说从其它软件系统导入/导出数据，必须在此说明。

　　4.4 约束和假定

　　描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。

　　另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。这种情况下，要求清楚地描述与本系统有交互的软件类型以及这样导致的约束。

　　实现的语言和平台也会对系统有约束，同样在此予以说明。

　　对于因选择具体的设计实现而导致对系统的约束，简要地描述你的想法思路，经过怎么样的权衡，为什么要采取这样的设计等等。

　　5 对象模型

　　提供整个系统的对象模型，如果模型过大，按照可行的标准把它划分成小块，例如可以把客户端和服务器端的对象模型分开成两个图表述。在其中应该包含所有的系统对象。这些对象都是从理解需求后得到的。要明确哪些应该、哪些不应该被放进图中。所有对象之间的关联必须被确定并且必须指明联系的基数。聚合和继承关系必须清楚地确定下来。每个图必须附有简单的说明。

　　6 对象描述

　　在这个部分叙述每个对象的细节，它的属性、它的方法。在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好。

　　为每个对象做一个条目。在系统对象模型中简要的描述它的用途、约束(如只能有一个实例)，列出它的属性和方法。如果对象是存储在持久的数据容器中，标明它是持久对象，否则说明它是个临时对象(transient object)。

　　对每个对象的每个属性详细说明：名字、类型，如果属性不是很直观或者有约束(例如，每个对象的该属性必须有一个唯一的值或者值域是有限正整数等)。

　　对每个对象的每个方法详细说明：方法名，返回类型，返回值，参数，用途以及使用的算法的简要说明(如果不是特别简单的话)。如果对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明。列出它或者被它调用的方法需要访问或者修改的属性。最后，提供可以验证实现方法的测试案例。

　　7 动态模型

　　这部分的作用是描述系统如何响应各种事件。一般使用顺序图和状态图。

　　确定不同的场景(Scenario)是第一步，不需要确定所有可能的场景，但是必须至少要覆盖典型的系统用例。不要自己去想当然地创造场景，通常的策略是描述那些客户可以感受得到的场景。

　　7.1 场景(Scenarios)

　　对每个场景做一则条目，包括以下内容：

　　场景名：给它一个可以望文生义的名字

　　场景描述：简要叙述场景是干什么的以及发生的动作的顺序。

　　顺序图：描述各种事件及事件发生的相对时间顺序。

　　7.2 状态图

　　这部分的内容包括系统动态模型重要的部分的状态图。可能你想为每个对象画一个状态图，但事实上会导致太多不期望的细节信息，只需要确定系统中一些重要的对象并为之提供状态图即可。

　　8 非功能性需求