面向对象分析文档模板Word格式.docx

1、1. 概述1.1 系统简述系统来源或者背景；系统要完成什么任务；所面向的用户；系统运行的环境的简短描述。这部分主要来源于需求说明书的开始部分。1.2 软件设计目标这部分论述整个系统的设计目标，明确地说明要实现哪些功能。对非功能性的需求例如性能、可用性、安全性、可靠性、可移植性等，亦需提及。需求规格说明书对于这部分的容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特点和功能。在随后的文档部分，将解释设计是怎么来实现这些功能的。1.3 参考资料列出本文档中所引用的参考资料。（至少要引用需求规格说明书），格式如下）：

2、（序号 作者. 书籍或者论文名称. 或者期刊名称, 出版年.月如果是期刊后面必须有起止页码，格式如下：1 董国林,鑫. 基于STC单片机的指纹考勤系统设计. 工业控制计算机,2012.11（25）:110-1112 林.巴斯等. 软件构架实践. 清华大学, 2003.8 2. 术语表对本文档中所使用的各种专业术语、容易引起歧义的术语以及自定义的术语进行说明。如果一些术语在需求规格说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。3. 用例3.1 用例图3.2 用例描述此处要求系统用用例图表述（UML），对每个用例（正常处理的情况）要有中文叙述。用例中请将事件进行标注。 用例序号（

3、如：用例1）：用例名称（如：年度学籍审查）对该用例进行一句或两句简短描述参与者（如：教学秘书）包含、扩展或泛化该用况所包含、可扩展的用例，以及包含或扩展它的用例；或者该用例的子用例或者父用例前置条件启动此用况所必须具备的条件。后置条件在该用况结束时确保成立的条件。工作流描述该用况的细节。（基本流与可选流）例外在该用况的执行的过程中可能引起的例外。限制在应用中可能出现的任何限制。注释提供可能对该用况是重要的任何附加信息。其中工作流的描述如下模板：研究生启动系统；系统提示研究生输入研究生证号和密码；研究生输入研究生证号和密码；系统进行验证，给出验证信息；若通过，若该生选择选课系统在扩展点”选课”处

4、执行用况“选课”；若通过，若该生选择查看学分系统在扩展点”查看学分”处执行用况“查看学分”4. 设计概述（此处请用简单的结构化描述）4.1 简述这部分要求突出整个设计所采用的方法（是面向对象设计还是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose）4.2 系统结构设计这部分要求提供高层系统结构的描述，使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离，对前者进行描述。别忘了说明图中用到的俗语和符号。4.2.1 顶层系统结构4.2.2 子系统1结构4.2.3 子系统2结构4.3 系统界面各种提供给用户的界面以及外部系统在此

5、处要予以说明。如果在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，可以指引读者参考需求说明。如果系统提供了对其它系统的接口，比如说从其它软件系统导入/导出数据，必须在此说明。4.4 约束和假定描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。这种情况下，要求清楚地描述与本系统有交互的软件类型（比如某某某数据库软件，某某某EMail软件）以及这样导致的约束（比如只允许纯文本的Email）。实现的语言和平台也会对系统有约束，同样在此予以说

6、明。对于因选择具体的设计实现而导致对系统的约束，简要地描述你的想法思路，经过怎么样的权衡，为什么要采取这样的设计等等。5. 对象模型5.1 类定义提供整个系统的对象模型，如果模型过大，按照可行的标准把它划分成小，例如可以把客户端和服务器端的对象模型分开成两个图表述。对象图应该包含什么呢？在其中应该包含所有的系统对象。这些对象都是从理解需求后得到的。要明确哪些应该、哪些不应该被放进图中。所有对象之间的关联必须被确定并且必须指明联系的基数（一对一、一对多还是多对多，0.1，*，1.*）。聚合和继承关系必须清楚地确定下来。每个图必须附有简单的说明。可能经过多次反复之后才能得到系统的正确的对象模型。5

7、.2 类关联描述请文字描述类关联请画出初始对象图5.3 对象模型图6. 对象数据字典描述在这个部分叙述每个对象的细节，它的属性、它的方法。在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好。为每个对象做一个条目。在系统对象模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。如果对象是存储在持久的数据容器中，标明它是持久对象，否则说明它是个临时对象（transient object）。对每个对象的每个属性详细说明：名字、类型，如果属性不是很直观或者有约束（例如，每个对象的该属性必须有一个唯一的值或者值域是有限正整数等）。对每个对象的每个方法详细说明：方

8、法名，返回类型，返回值，参数，用途以及使用的算法的简要说明（如果不是特别简单的话）。如果对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明。列出它或者被它调用的方法需要访问或者修改的属性。最后，提供可以验证实现方法的测试案例。6.1 子系统1中的对象6.1.1 对象：对象1用途：约束：持久性：6.1.1.1 属性描述：1. 属性：属性1类型：描述：2. 属性：属性26.1.1.2 方法描述：1. 方法：方法1返回类型：参数：返回值：Pre-Condition：Post-Condition：读取/修改的属性：调用的方法：处理逻辑：测试例：用什

9、么参数调用该方法，期望的输出是什么7. 动态模型这部分的作用是描述系统如何响应各种事件。例如，可以建立系统的行为模型。一般使用顺序图和状态图。确定不同的场景（Scenario）是第一步，不需要确定所有可能的场景，但是必须至少要覆盖典型的系统用例。不要自己去想当然地创造场景，通常的策略是描述那些客户可以感受得到的场景。7.1 场景（Scenarios）对每个场景做一则条目，包括以下容：场景名：给它一个可以望文生义的名字场景描述：简要叙述场景是干什么的以及发生的动作的顺序。顺序图：描述各种事件及事件发生的相对时间顺序。7.1.1 场景：场景1动作1动作27.2事件定义（Events）文字定义事件画

10、出事件跟踪图画出事件流图7.3 状态图这部分的容包括系统动态模型重要的部分的状态图。可能你想为每个对象画一个状态图，但事实上会导致太多不期望的细节信息，只需要确定系统中一些重要的对象并为之提供状态图即可。7.3.1 状态图18. 功能模型8.1确定输入输出与事件关系8.2功能模型图功能模型图有很多，请分开表示8.2.1 对象1的功能模型图8.2.2 对象2的功能模型图9.数据库定义10. 部署图11. 非功能性需求在这个部分，必须说明如何处理需求文档中指定的非功能性需求。尽可能客观地评估系统应付每一个非功能性的需求的能力程度。如果某些非功能性需求没有完全在设计的系统中实现，请务必在此说明。另外，你也需要对系统将来的进化作一个估计并描述本设计如何使系统能够适应这些可预见的变化。12. 辅助文档提供能帮助理解设计的相应文档。13. 词汇索引