概要设计学习总结

第一章.     词汇表

第一节       模块（module）：一组完成指定功能的语句，包括：输入、输出、逻辑处理功能、内部信息、运行环境（与功能对应但不是一对一关系）。

第二节       组件（component）：系统中相当重要的、几乎是独立的可替换部分，它在明确定义的构架环境中实现确切的功能。

第三节       模式（pattern）：指经过验证，至少适用于一种实用环境（更多时候是好几种环境）的解决方案模板（用于结构和行为。在 UML 中：模式由参数化的协作来表示，但 UML 不直接对模式的其他方面（如使用结果列表、使用示例等，它们可由文本来表示）进行建模。存在各种范围和抽象程度的模式，例如，构架模式、分析模式、设计模式和代码模式或实施模式。模式将可以帮助我们抓住重点。构架也是存在模式的。比如，对于系统结构设计，我们使用层模式；对于分布式系统，我们使用代理模式（通过使用代理来替代实际的对象，使程序能够控制对该对象的访问）；对于交互系统，我们使用MVC（M模型(对象)／V视图(输出管理)／C控制器(输入处理)）模式。模式是针对特定问题的解，因此，我们也可以针对需求的特点采用相应的模式来设计构架。

第四节       构架模式（architectural pattern）：表示软件系统的基本结构组织方案。它提供了一组预定义的子系统、指定它们的职责，并且包括用于组织其间关系的规则和指导。

第五节       层（layer）：对模型中同一抽象层次上的包进行分组的一种特定方式。通过分层，从逻辑上将子系统划分成许多集合，而层间关系的形成要遵循一定的规则。通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。（层是对构架的横向划分，分区是对构架的纵向划分）。

第六节       系统分层的几种方法

1.         常用三层服务：用户层、业务逻辑层、数据层

2.         多层结构的技术组成模型：表现层、中间层、数据层；

3.          网络系统常用三层结构：核心层、汇聚层和接入层；

4.          RUP典型分层方法：应用层、专业业务层、中间件层、系统软件层；

5.          基于Java的B/S模式系统结构：浏览器端、服务器端、请求接收层、请求处理层；

6.          某六层结构：功能层（用户界面）、模块层、组装层（软件总线）、服务层（数据处理）、数据层、核心层；

第七节       构架（Architecture，愿意为建筑学设计和建筑物建造的艺术与科学）: 在RUP中的定义：软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互；《软件构架实践》中的定义：某个软件或者计算系统的软件构架即组成该系统的一个或者多个结构，他们组成软件的各个部分，形成这些组件的外部可见属性及相互间的联系；IEEE 1471-2000中的定义：the fundamental organization of a system emboided in its components,their relationships to each other,and to the enviroment and the principles guiding its design and evolution，构架是系统在其所处环境中的最高层次的概念。软件系统的构架是通过接口交互的重要构件（在特定时间点）的组织或结构，这些构件又由一些更小的构件和接口组成。（“构架”可以作为名词，也可作为动词，作为动词的“构架”相当于“构架设计”）

第八节       构架的描述方式：“4＋1”视图（用例视图、设计视图、实现视图、过程视图、配置视图）是一个被广为使用的构架描述的模型；RUP过程的构架描述模板在“4＋1”视图的基础上增加了可选的数据视图（从永久性数据存储方面来对系统进行说明）；HP公司的软件描述模板也是基于“4＋1”视图。

第九节       、结构：软件构架是多种结构的体现，结构是系统构架从不同角度观察所产生的视图。就像建筑物的结构会随着观察动机和出发点的不同而有多种含义一样，软件构架也表现为多种结构。常见的软件结构有：模块结构、逻辑或概念结构、进程或协调结构、物理结构、使用结构、调用结构、数据流、控制流、类结构等等。

第二章.     概要设计写什么?(概要设计怎么做)

第一节       目的

1.         将软件系统需求转换为未来系统设计

2.         逐步开发强壮的系统架构

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

4.         结构应该分解为模块和库

第二节       任务

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

2.         总体结构设计：

a)         功能（加工）－>模块：每个功能用那些模块实现，保证每个功能都有相应的模块来实现

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

c)         模块间的接口：传递的信息及其结构；

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

e)         用户界面设计；

f)         数据结构设计：
  详细的数据结构：表、索引、文件；
  算法相关逻辑数据结构及其操作；上述操作的程序模块说明（在前台？在后台？用视图？用过程？······）

g)        接口控制表的数据结构和使用规则

h)        其他性能设计。

3.         写什么？

a)         任务：目标、环境、需求、局限；

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

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

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

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

f)         运行设计：运行模块组合、控制、时间；

g)        出错设计：出错信息、处错处理；

h)        其他设计：保密、维护；

i)          附录

OO软件设计说明书结构
  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 非功能性需求

      

第三章.     怎么做概要设计

第一节       详细阅读需求规格说明书，理解系统建设目标、业务现状、现有系统、客户需求的各功能说明；

第二节       分析数据流图，弄清数据流加工的过程；

第三节       根据数据流图决定数据处理问题的类型（变换型、事务型、其他型）；

第四节       通过以上分析，推导出系统的初始结构图；

第五节       对初始结构图进行改进完善：所有的加工都要能对应到相应模块（模块的完整性在于他们完成了需求中的所有加工），消除完全相似或局部相似的重复功能（智者察同），理清模块间的层次、控制关系，减少高扇出结构，随着深度增大扇入，平衡模块大小。

第六节       由对数据字典的修改补充完善，导出逻辑数据结构，导出每种数据结构上的操作，这些操作应当属于某个模块。

第七节       确定系统包含哪些应用服务系统、客户端、数据库管理系统；

第八节       确定每个模块放在哪个应用服务器或客户端的哪个目录、哪个文件（库），或是在数据库内部建立的对象。

第九节       对每个筛选后的模块进行列表说明。

第一零节              对逻辑数据结构进行列表说明。

第一一节              根据结构化软件设计说明书结构对其他需要说明的问题进行补充说明，形成概要设计说明书。

第一二节              附录

     在OOA基础上设计对象与类：在问题领域分析（业务建模和需求分析）之后，开始建立系统构架。
     第一步是抽取建立领域的概念模型，在UML中表现为建立对象类图、活动图和交互图。对象类就是从对象中经过“察同”找出某组对象之间的共同特征而形成类：
     对象与类的属性：数据结构；
     对象与类的服务操作：操作的实现算法；
     对象与类的各外部联系的实现结构；
     设计策略：充分利用现有的类；
     方法：继承、复用、演化；
     活动图用于定义工作流，主要说明工作流的5W（Do What、Who Do、When Do、Where Do、Why Do）等问题，交互图把人员和业务联系在一起是为了理解交互过程，发现业务工作流中相互交互的各种角色。
     第二步是构建完善系统结构：对系统进行分解，将大系统分解为若干子系统，子系统分解为若干软件组件，并说明子系统之间的静态和动态接口，每个子系统可以由用例模型、分析模型、设计模型、测试模型表示。软件系统结构的两种方式：层次、块状
  层次结构：系统、子系统、模块、组件（同一层之间具有独立性）；
  块状结构：相互之间弱耦合
  系统的组成部分：
  问题论域：业务相关类和对象(OOA的重点)；
  人机界面：窗口、菜单、按钮、命令等等；
  数据管理：数据管理方法、逻辑物理结构、操作对象类；
  任务管理：任务协调和管理进程；
    第三步是利用“4＋1”视图描述系统架构：用例视图及剧本；说明体系结构的设计视图；以模块形式组成包和层包含概要实现模型的实现视图；说明进程与线程及其架构、分配和相互交互关系的过程视图；说明系统在操作平台上的物理节点和其上的任务分配的配置视图。在RUP中还有可选的数据视图。
     第四步是性能优化（速度、资源、内存）、模型清晰化、简单化（简单就是享受）。

第四章.     概要设计考虑因素

第一节       程序的运行时结构方面的考虑：
  1） 需求的符合性：正确性、完整性；功能性需求、非功能性需求；
  2） 总体性能（内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响）；
  3） 运行可管理性：便于控制系统运行、监视系统状态、错误处理；模块间通信的简单性；与可维护性不同；
  4） 与其他系统接口兼容性；
  5） 与网络、硬件接口兼容性及性能；
  6） 系统安全性；
  7） 系统可靠性；
  8） 业务流程的可调整性；
  9） 业务信息的可调整性
  10） 使用方便性
  11） 构架样式的一致性

第二节       程序的运行时结构方面的考虑：
  1） 需求的符合性：正确性、完整性；功能性需求、非功能性需求；
  2） 总体性能（内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响）；
  3） 运行可管理性：便于控制系统运行、监视系统状态、错误处理；模块间通信的简单性；与可维护性不同；
  4） 与其他系统接口兼容性；
  5） 与网络、硬件接口兼容性及性能；
  6） 系统安全性；
  7） 系统可靠性；
  8） 业务流程的可调整性；
  9） 业务信息的可调整性
  10） 使用方便性
  11） 构架样式的一致性

第五章.     概要设计原则

第一节         总体原则和方法：由粗到细的原则，互相结合的原则，定性分析和定量分析相结合的方法，分解和协调的方法和模型化方法。

第二节       要系统考虑系统的一般性、关联性、整体性和层次性。

第三节       分解协调：目的是为了创造更好的系统。系统分解是指将一个复杂的系统分解为若干个子系统，系统协调一是系统内协调，即根据系统的总结构、总功能、总任务和总目标的要求，使各个子系统之间互相协调配合，在各个子系统局部优化基础上，通过内部平衡的协调控制，实现系统的整体优化；

第四节       屏蔽抽象：从简单的框架开始，隐含细节；

第五节       一致性：统一的规范、统一的标准、统一的文件模式；

第六节       每个模块应当有一个统一命名的容易理解的名字；

第七节       编码：由外向内（界面－>核心）；

第八节       面向用户：概要设计是对于按钮按下后系统“怎么做”的简要说明；

第九节       模块、组件的充分独立性、封闭性；

第一零节              同时考虑静态结构与动态运行

第一一节              每个逻辑对象都应当说明其所处物理对象（非一一对应）；

第一二节              每个物理对象都有合适的开发人员，并且利于分工与组装。（

第一三节              确立每个构架视图的整体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口；

第一四节              软件构架与使用的技术平台密切相关，目前常用的平台有J2EE、.NET、CORBA等等，因此具体的软件构架人员应当具备使用这些平台的软件开发经验；

第一五节              通过需求功能与设计模块之间的列表对应，检查每个需求功能是否都有相应的模块来实现，保证需求功能的可追溯性和需求实现（模块）的完整性，同时可以检查重复和不必要的模块。

第六章.     概要设计的输出

第一节       编码规范：信息形式、接口规约、命名规则；

第二节       物理模型：组件图、配置图；

第三节       不同角度的构架视图：用例视图、逻辑视图、进程视图、部署视图、实施视图、数据视图（可选）；

第四节       系统总体布局：哪些部分组成、各部分在物理上、逻辑上的相互关系；

第五节         两个不可忽视的输出：

1.           与需求功能的关系：对于需求中的每一个功能，用哪一层、哪个模块、哪个类、哪个对象来实现（一对多关系）；反过来，应当说明将要创建的系统每一层、每个模块、每个对象、每一个类“做什么”，他们是为了帮助实现哪些功能（一对多关系）。（需求的颗粒度在一开始往往是比较粗的，因此根据功能点对于整体项目规模的估计或得到项目WBS其误差范围也是比较大的。更为重要的原因是，需求往往不是编码工作分解的准确依据，因为一个需求的功能点可能对应多个代码模块，而多个需求的功能点也可能只对应一个或少数代码模块，同时还有软件复用等因素要考虑，因此只有在概要设计完成以后才能准确地得到详细设计或编码阶段的二次 WBS，并估计较为准确的整体项目规模。）

2.           逻辑与物理位置：每个对象在逻辑上分别落在哪一层、哪个模块、哪个类；在物理上每个模块、每个对象、每一个类放在哪个应用服务器或客户端的哪个目录、哪个文件（库），或者是建立在数据库管理系统中的什么东东（过程、函数、视图、触发器等等）。

第七章.     如何判断设计的模块是完整的？

第八章.     为什么设计阶段不宜过于重视业务流程？

在需求调研分析过程中对业务处理过程了解的完整性和准确性非常重要。调查了解清楚所有的业务流程才能设计出适合各流程业务节点用户业务特点和习惯的软件，使开发出来的软件更受欢迎。当然在进行软件概要设计时，要尽量排除业务流程的制约，即把流程中的各项业务结点工作作为独立的对象，设计成独立的模块，充分考虑他们与其他各种业务对象模块的接口，在流程之间通过业务对象模块的相互调用实现各种业务，这样，在业务流程发生有限的变化时（每个业务模块本身的业务逻辑没有变的情况下），就能够比较方便地修改系统程序模块间的调用关系而实现新的需求。如果这种调用关系被设计成存储在配置库的数据字典里，则连程序代码都不用修改，只需修改数据字典里的模块调用规则即可。

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

第一零章.            结构化还是面向对象

第一节       从概念方面看，结构化软件是功能的集合，通过模块以及模块和模块之间的分层调用关系实现；面向对象软件是事物的集合，通过对象以及对象和对象之间的通讯联系实现；

第二节       从构成方面看，结构化软件＝过程＋数据，以过程为中心；面向对象软件＝（数据＋相应操作）的封装，以数据为中心；

第三节       从运行控制方面看，结构化软件采用顺序处理方式，由过程驱动控制；面向对象软件采用交互式、并行处理方式，由消息驱动控制；

第四节       从开发方面看，结构化方法的工作重点是设计；面向对象方法的工作重点是分析；但是，在结构化方法中，分析阶段和设计阶段采用了不相吻合的表达方式，需要把在分析阶段采用的具有网络特征的数据流图转换为设计阶段采用的具有分层特征的结构图，在面向对象方法中则不存在这一问题。

第五节       从应用方面看，相对而言，结构化方法更加适合数据类型比较简单的数值计算和数据统计管理软件的开发；面向对象方法更加适合大型复杂的人机交互式软件和数据统计管理软件的开发；