详细设计说明书(模板).doc

XX系统 详细设计说明书 广东创我科技发展有限公司 修订记录 日期 修订版本 修改描述 作者 审核 目 录 第一章 概述 5 1.1. 应用模块的目的 5 1.2. 应用模块总体描述 5 1.3. 应用模块接口描述 5 1.4. 假设条件 5 第二章 设计模式（Design pattern） 6 第三章 类设计 7 3.1. 分块类图 8 3.1.1. 类图1 8 3.1.2. 类图n 8 3.2. 整体继承关系 8 3.3. 类描述 9 3.3.1. 类名1 Class Description 9 3.3.2. 类名n Class Description 10 第四章 交互图 12 4.1. 情景编号1: 情景名称 12 4.1.1. 交互图 12 4.1.2. 例外情况及条件 13 4.2. 情景编号n: 情景名称 13 第五章 状态图 14 5.1. 状态图编号1:状态图名称 14 5.2. 状态图编号n:状态图名称 15 第六章 时序流程图 16 第七章 用户界面设计说明 18 7.1. 用户界面关系 18 7.2. 用户界面具体描述 18 7.2.1. 界面编号1:界面名称〉 18 7.2.2. 界面编号N:界面名称〉 19 第八章 测试考虑 20 第九章 附录 21 9.1. 附录A 代码举例 21 9.2. 附录B 设计问题 21 9.2.1. 设计问题1 21 9.2.2. 设计问题n 21 概述 应用模块的目的 请明确客户建立应用模块的目的。 应用模块总体描述 描述应用模块的总体功能。 应用模块接口描述 简要描述本应用模块的公共接口，具体接口会在相应的类中进行具体描述。建议采用列表的方式。 假设条件 列出在问题领域，项目方案及其它影响系统设计的可能方面内，应当成立的假设条件。包括系统的约束条件和应遵循的标准。 设计模式（Design pattern） 请列出本模块设计时使用的设计模式，请参考 “Design Patterns” By Erich Gramma, Helm, Johnson Vlissides, gang of four ISBN 0-201-63361-z (中文《设计模式》-机械工业出版社)。 类设计 类图(Class Diagram)描述类和类之间的静态关系。与数据模型不同,它不仅显示了信息的结构,同时还描述了系统的行为。 在类图的基础上，利用状态图、关系图等进一步描述了系统其他方面的特性。 类图主要描述了： 类（包括类的实例） 属性（表示知识型责任或数据） 方法（表示操作责任或功能） 类之间的关联关系 类之间的聚合关系 在父类及子类之间的继承关系 正式或非正式的约束描述（可选） 本节针对每个构件的进行了详细描述， 记录每个类的实例数，每个实例的占用数据库空间的平均大小等信息。 类图的设计在整个项目生命周期内通过迭代的方法得到。方案的复杂程度决定迭代的次数。 在考虑初始(initial)或概念(conceptual)角度类图时，我们讨论系统作什麽，该阶段即传统意义上的分析阶段，通过理解业务模型的哪些业务模型应在软件系统中实现来定义问题和需求。在这点上设计保持技术中立，但并不意味着丝毫不考虑技术，因为此时对于如何构造软件系统的决定不是首要的关注问题。 下一步，设计逻辑(logical)或具体(specification)角度类图时，开始关心系统如何实施和定义方案的整体结构。诸如并行及分发，协作及共享，交易及存储，用户界面性能，及系统接口例如通讯接口。在设计阶段，设计依赖于技术和架构，同时设计决策也会影响技术和架构。 最后的迭代是设计物理或实施角度类图，基于所选的实施语言细化架构设计。为了处理特定的实施细节，我们可能引入新的类或对现有的类进行重新定制。 请明确本节描述的是何种角度的类图。 类图的目的在于通过研究业务、用户及系统的需求，制定全面的软件模型。创建完善的类图有助于完成如下工作: 通过研究系统中包含的对象，优化并精简系统。 是系统应用架构某些层次设计的出发点，如用户界面、数据库建模。 通过分析问题所在及其相关领域，恰当建立对象模型，有助于明确分工，以支持并行开发。 通过使用简洁明了的表示方法，进一步确认系统设计。 全面考虑使用合适的应用设计模