目 录
1.5 术语与缩写解释
架构 (Architecture): 系统在其所处环境中的最高层次的概念，涉及系统的组织结构。软件系统的架构是通过接口交互的重要构件（在特定时间点）的组织或结构，这些构件又由一些更小的构件和接口组成。架构可以递归解构为部件之间的接口、部件之间关系以及被组装部件之间的约束。
SD: 系统设计，System Design
XML: (eXtend Markable Language, 扩展标记语言)，用严格的嵌套标记表示数据信息，特别适合在Internet环境中的多点数据交换环境下使用
SOAP: （Simple Object Access Protocol，简单对象访问协议）， 用来定义数据描述和远程访问的标准.
WSDL: （Web Services Description Language，Web服务描述语言）， 是发布和请求Web服务的描述语言.
UDDI: （Universal Description, Discovery and Integration，统一描述、发现和集成），把Web服务与用户联系起来，起中介作用。
OMT: (Object-Oriented Modeling Technique OMT) 面向对象的建模技术.
Design patterns: 模式是在一个上下文中，对一个问题的解决方案。即模式的四要素：名字、上下文、问题和解决方案。分为23种设计模式：创建型：5种;结构型：7种;行为型：11种.
2. 系统的架构分析
1，架构分析主要包括：确定分析机制，确定核心的抽象概念，定义子系统的高层组织，创建用例实现。
2，对用例分析包括：补充用例规约，查找分析类，确定分析类的细节，限定分析类的分析机制。
3，确定设计元素。
4，确定设计机制。
5，描述运行时架构。
6，描述分布。
本系统可采用OMT对进行架构分析设计
用OMT方法对系统进行分析通常分两步：
第一步是对问题的描述；
第二步是将对问题的描述建立成三种模型，即对象模型、动态模型、功能模型。
2.1 本系统“是什么”
系统建模方法是从系统的问题描述开始的，详细精确的问题描述能使开发人员的分析、设计更为合理、准确。这里首先建立理想模型，做行为分析。
主要包括:
2.1.1 访问者定义
谁将是该项目的访问者？访问者的目的是什么？访问者能获到什么信息？进行何种商务功能的处理？或者得到什么形式的奖励？
2.1.2 创建情节
根据访问者定义，找出能代表大多数访问者的人，举例说明用户的真实网上经历，如何完成一定的任务，就象讲述一个网民上网的故事，可以尽量发挥想象力去描述。
2.1.3 竞争性分析
浏览和评估一至二个我们主要的竞争对手的网站，严肃客观地评价竞争者，分析出该项目在竞争上的优势。
可以使用下表:
网站名
网址
功能描述
优势分析
2.2 本系统的主要功能
2. 系统的架构分析
1，架构分析主要包括：确定分析机制，确定核心的抽象概念，定义子系统的高层组织，创建用例实现。
2，对用例分析包括：补充用例规约，查找分析类，确定分析类的细节，限定分析类的分析机制。
3，确定设计元素。
4，确定设计机制。
5，描述运行时架构。
6，描述分布。
本系统可采用OMT对进行架构分析设计
用OMT方法对系统进行分析通常分两步：
第一步是对问题的描述；
第二步是将对问题的描述建立成三种模型，即对象模型、动态模型、功能模型。
2.1 本系统“是什么”
系统建模方法是从系统的问题描述开始的，详细精确的问题描述能使开发人员的分析、设计更为合理、准确。这里首先建立理想模型，做行为分析。
主要包括:
2.1.1 访问者定义
谁将是该项目的访问者？访问者的目的是什么？访问者能获到什么信息？进行何种商务功能的处理？或者得到什么形式的奖励？
可以使用下表(简化的用例):
| 信息 | 商务处理 | 奖励 |
|
|
|
|
| 综 述（如有必要再进行全方面的描述，请填写在下面） | ||
|
| ||
2.1.2 创建情节
根据访问者定义，找出能代表大多数访问者的人，举例说明用户的真实网上经历，如何完成一定的任务，就象讲述一个网民上网的故事，可以尽量发挥想象力去描述。
2.1.3 竞争性分析
浏览和评估一至二个我们主要的竞争对手的网站，严肃客观地评价竞争者，分析出该项目在竞争上的优势。
可以使用下表:
| 网站名 |
|
|
| 网址 |
|
|
| 功能描述 |
|
|
| 优势分析 |
|
|
2.2 本系统的主要功能
根据上述问题描述，需要对系统的功能做详细描述，以构造出系统顶层的对象图、状态图和数据流图，
2.2.1 项目内容和功能的输入
（1）项目内容概述（项目具有哪些内容？哪些功能？列出所需的内容和功能的清单。）
（2）项目内容分组和命名（将内容进行分组，也即分成若干个栏目，给每栏起一个名字，中文英文各取一个，中文的用做导航，英文的作为网站文件目录的名字。）
（3）功能需求（列出项目中用户功能性的内容）
2.2.2 项目结构
（1）结构列表
建立一个基于文本形式的项目层次结构图，结构如下（摘自《云南移动门户网站手机俱乐部频道策划》）：
（2）建立结构蓝图，定义全局和局部导航。
结构蓝图是网站结构的可视化表示，显示网站中的元素如何分组和联系的图表，不同的内容（静态或是动态的）和功能使用不同的几何形状进行表示，整个结构呈现倒树状，内容要素和功能要素使用不同的方法表示。
可用表的示例：
|
| 主线程 | 分线程 | 时间 （天） | 所在分线程时间比 | 所在总线程时间比 |
| 前 台 开 发 | 设计阶段 | 参考 |
|
|
|
| 设计框架 |
|
|
| ||
| 设计装饰图片 |
|
|
| ||
| 完成设计整合 |
|
|
| ||
| 制作阶段 | 设计CSS |
|
|
| |
| 制作框架html |
|
|
| ||
| 加入代码 |
|
|
| ||
| 作代码优化 |
|
|
| ||
| 设计制作 整合 | 与策划人员沟通 |
|
|
| |
| 在后台代码加入后，根据项目小组意见进行整合 |
|
|
| ||
| WEB 服 务 开 发 | WEB 服务层 开发 | 审阅功能规范 |
|
|
|
| 确定模块化/分层设计参数 |
|
|
| ||
| 分派任务 |
|
|
| ||
| 编写代码 |
|
|
| ||
| 开发人员测试（初步调试） |
|
|
| ||
| 上传功能模块 |
|
|
| ||
| 数 据 库 开 发 | 数据库开发 | 审阅功能规范 |
|
|
|
| 确定表/过程设计参数 |
|
|
| ||
| 分派任务 |
|
|
| ||
| 编写代码 |
|
|
| ||
| 开发人员测试（初步调试） |
|
|
| ||
| 上传功能模块 |
|
|
|
2.2.3 备选的分析机制
项目的分析机制还包括
• 永久性
• 安全性
• 分布
• 进程通讯
• 错误报告
• 格式转换
• 消息路由
• 进程控制与同步
• 事务管理
• 信息交换
• 冗余度
2.3 系统的架构机制
架构机制采用MVC(Model-View-Control)，见设计模式，
2.3.1 MVC结构如下图
2.3.2 定义过程流
然后定义过程流（Process Flow）。
使用UML描述，包括以下内容；
1，描述设计对象的交互
2，使用子系统简化序列图
3，描述永久性相关行为
4，改进事件流描述
输入的用例见附录1表：
2.3.3 对象交互图
对象交互图包括：请求处理序列图，事件处理序列图，使用UML描述。
2.3.4 类设计—从分析类到设计类
从分析类到设计类的过程：可采用如下表（示例）
详细描述：
示例：分析类
LoginInfoScreen身份及口令信息
2.3.5 数据库设计
需要考虑：
对系统中信息流有严格的顺序关系。
建立强大的查询和统计功能，用户只需要对要查询的数据进行简单的选择和组合即可得到查询结果。
灵活的授权管，用户权限分为三级：超级用户、部门级用户、单据级用户。不同的用户其权限不同。
2.3.6基于Web浏览器的多层结构开发模式
主流的软件架构B/S与N Tier模式都有一些缺点，所以现在出现了许多B－N Tier的系统，就是基于Web浏览器的多层结构开发模式，它吸收了两者的优点。
单纯的B/S方式，虽然可以认为实现了最终用户使用成本几乎为零，但它存在许多不足，它的功能较弱，无法非常容易地实现你的理念。比如你要实现一种商业模型，你会发现实际上Web方式是不安全、不可靠的，比如，用户可通过页面回退或前进来改变你所有希望的结果、报表制作能力不足等（当然这也取决于业务的复杂程度）。
为什么Web会造成逻辑实现上的困难？因为它是基于Stateless（无状态）的，Stateless就是这样一种情形：不知道用户端是什么样子，接收信息是不可控的，不知道传递给他的信息的流向，这就是Stateless。所有基于HTTP的东西都是Stateless的。而Socket的魅力就在于它是有状态的。
现在发展起来的ASP、JSP、Java技术，虽然弥补了HTTP协议存在的无状态缺陷，但即使这些技术再先进，也无法解决HTTP协议基于Stateless的事实。 以基于IIS的ASP技术来说，它使用Session变量来实现State。但是不管什么技术，最终都落在了COOKIE上，也就是使用COOKIE来保留客户端状态。
Socket目前应用十分广泛，ICQ、QQ等即时通讯软件，还有许多网络工具，大都基于Socket，因为Socket协议是有状态的，所以才能做到这一点。可以这么说，是Socket让网络生活更精彩！
目前基于Web的多层结构采用的底层技术主要有SOAP＋State类协议或者HTTP＋State类协议。从Delphi 6开始引入WebSnap包（一种Web Provider产品）。它同时支持HTTP与SOAP协议，也采用了一种类似Session变量的模式来实现有状态(State)。它可以说是目前市面上最强大的基于平台的Browse/Server开发工具之一，不足是它还不能称为完全的RAD工具，且门槛较高。在Delphi 7中还引入了IntraWeb控件包，它是一种真正意义上的网页RAD开发工具，与WebSnap配合更好。
Web Provider、逻辑组件、多线程处理、交易机制、消息流转等组合在一起是N Tier开发的高境界，所以是大型商业软件架构的首选。
另外还需要考虑消息机制，消息机制并不一定在所有的多层结构中都存在，而且，如果要实现消息机制，必须寻找实现手段（比如使用Socket），否则，如果在程序中强制实施大量消息流转（比如使用定时器监控和消息数据表方式），无论是效率还是实现的复杂性来讲都是要考虑的问题。
3. 概要设计
架构设计的描述—概要设计说明
3.1 概要设计的目的
概要设计的目的主要即设计系统架构，包括：
1，将软件系统需求转换为未来系统的设计；
2，逐步开发强壮的系统架构；
3，使设计适合于实施环境，为提高性能而进行设计；
4，结构应该被分解为模块和类。
3.2 概要设计的任务
概要设计的任务包括：
1，制定规范
制订项目组的代码体系、接口规约、命名规则。这是项目小组今后共同作战的基础，有了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法，大家就有了共同的工作语言、共同的工作平台，使整个软件开发工作可以协调有序地进行。
2，总体结构设计
功能（加工）－>模块：每个功能用那些模块实现，保证每个功能都有相应的模块来实现；
模块层次结构：某个角度的软件框架视图；
模块间的调用关系：模块间的接口的总体描述；
模块间的接口：传递的信息及其结构；
处理方式设计：满足功能和性能的算法
3，用户界面设计
（略）
4，数据结构设计
详细的数据结构：表、索引、文件；
算法相关逻辑数据结构及其操作；
上述操作的程序模块说明（在前台？在后台？用视图？用过程？······）
接口控制表的数据结构和使用规则
5，其他性能设计
主要是压力性能的考虑。
3.3 概要设计的原则
总体原则和方法：由粗到细的原则，互相结合的原则，定性分析和定量分析相结合的方法，分解和协调的方法和模型化方法。
要系统考虑系统的一般性、关联性、整体性和层次性。
分解协调：目的是为了创造更好的系统。系统分解是指将一个复杂的系统分解为若干个子系统，系统协调一是系统内协调，即根据系统的总结构、总功能、总任务和总目标的要求，使各个子系统之间互相协调配合，在各个子系统局部优化基础上，通过内部平衡的协调控制，实现系统的整体优化；
屏蔽抽象：从简单的框架开始，隐含细节；
一致性：统一的规范、统一的标准、统一的文件模式；
每个模块应当有一个统一命名的容易理解的名字；
编码：由外向内（界面－>核心）；
面向用户：概要设计是对于按钮按下后系统“怎么做”的简要说明；
模块、组件的充分独立性、封闭性；
同时考虑静态结构与动态运行；
每个逻辑对象都应当说明其所处物理对象（非一一对应）；
每个物理对象都有合适的开发人员，并且利于分工与组装。（详细说明见本人另一篇文章：系统架构设计应考虑的因素）；
确立每个架构视图的整体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口；
软件架构与使用的技术平台密切相关，目前常用的平台有J2EE、.NET、CORBA等等，因此具体的软件架构人员应当具备使用这些平台的软件开发经验；
通过需求功能与设计模块之间的列表对应，检查每个需求功能是否都有相应的模块来实现，保证需求功能的可追溯性和需求实现（模块）的完整性，同时可以检查重复和不必要的模块。
在需求调研分析过程中对业务处理过程了解的完整性和准确性非常重要。调查了解清楚所有的业务流程才能设计出适合各流程业务节点用户业务特点和习惯的软件，使开发出来的软件更受欢迎。当然在进行软件概要设计时，要尽量排除业务流程的制约，即把流程中的各项业务结点工作作为独立的对象，设计成独立的模块，充分考虑他们与其他各种业务对象模块的接口，在流程之间通过业务对象模块的相互调用实现各种业务，这样，在业务流程发生有限的变化时（每个业务模块本身的业务逻辑没有变的情况下），就能够比较方便地修改系统程序模块间的调用关系而实现新的需求。如果这种调用关系被设计成存储在配置库的数据字典里，则连程序代码都不用修改，只需修改数据字典里的模块调用规则即可。
3.4 概要设计的内容
1. 系统概述
(1）说明本系统“是什么”，（2）描述本系统的主要功能。
2. 设计约束
（1）需求约束。体系结构设计人员从需求文档（如《用户需求说明书》和《软件需求规格说明书》）中提取需求约束，例如：本系统应当遵循的标准或规范，软件、硬件环境（包括运行环境和开发环境）的约束，接口/协议的约束，用户界面的约束，软件质量的约束，如正确性、健壮性、可靠性、效率（性能）、易用性、清晰性、安全性、可扩展性、兼容性、可移植性等等。
（2）隐含约束。有一些假设或依赖并没有在需求文档中明确指出，但可能会对系统设计产生影响，设计人员应当尽可能地在此处说明。例如对用户教育程度、计算机技能的一些假设或依赖，对支撑本系统的软件硬件的假设或依赖等。
3. 设计策略
体系结构设计人员根据产品的需求与发展战略，确定设计策略（Design Strategy）。例如：扩展策略。说明为了方便本系统在将来扩展功能，现在有什么措施。复用策略。说明本系统在当前以及将来的复用策略。折衷策略。说明当两个目标难以同时优化时如何折衷，例如“时－空”效率折衷，复杂性与实用性折衷。
4. 系统总体结构
（1）将系统分解为若干子系统，绘制物理图和逻辑图，说明各子系统的主要功能。
（2）说明“如何”以及“为什么”（how and why）如此分解系统。
（3）说明各子系统如何协调工作，从而实现原系统的功能。接口设计：说明外部用户、软、硬件接口；内部模块间接口。
5. 子系统的结构与功能
（1）将子系统分解为模块（Module），绘制逻辑图（如果物理图和逻辑图不一样的话，应当绘制物理图），说明各模块的主要功能。
（2）说明“如何”以及“为什么”（how and why）如此分解子系统N。
（3）说明各模块如何协调工作，从而实现子系统的功能。每个模块“做什么”、简要说明“怎么做”（输入、输出、处理逻辑、与其它模块的接口，与其它系统或硬件的接口），处在什么逻辑位置、物理位置；
6. 开发环境的配置
说明本系统应当在什么样的环境下开发，有什么强制要求和建议？
计算机硬件，软件，网络通信，
7. 运行环境的配置
说明本系统应当在什么样的环境下运行，有什么强制要求和建议？
8. 测试环境的配置
说明本系统应当在什么样的环境下测试，有什么强制要求和建议？
（1）一般地，单元测试、集成测试环境与开发环境相同。
（2）一般地，系统测试、验收测试环境与运行环境相同或相似（更加严格）。
3.5 概要设计的输出
编码规范：信息形式、接口规约、命名规则；
物理模型：组件图、配置图；
不同角度的架构视图：用例视图、逻辑视图、进程视图、部署视图、实施视图、数据视图（可选）；
系统总体布局：哪些部分组成、各部分在物理上、逻辑上的相互关系；
两个不可忽视的输出：
与需求功能的关系：对于需求中的每一个功能，用哪一层、哪个模块、哪个类、哪个对象来实现（一对多关系）；反过来，应当说明将要创建的系统每一层、每个模块、每个对象、每一个类“做什么”，他们是为了帮助实现哪些功能（一对多关系）。（需求的颗粒度在一开始往往是比较粗的，因此根据功能点对于整体项目规模的估计或得到项目WBS其误差范围也是比较大的。更为重要的原因是，需求往往不是编码工作分解的准确依据，因为一个需求的功能点可能对应多个代码模块，而多个需求的功能点也可能只对应一个或少数代码模块，同时还有软件复用等因素要考虑，因此只有在概要设计完成以后才能准确地得到详细设计或编码阶段的二次WBS，并估计较为准确的整体项目规模。）
逻辑与物理位置：每个对象在逻辑上分别落在哪一层、哪个模块、哪个类；在物理上每个模块、每个对象、每一个类放在哪个应用服务器或客户端的哪个目录、哪个文件（库），或者是建立在数据库管理系统中的什么东东（过程、函数、视图、触发器等等）。
4 数据库设计
4.1 数据库设计的内容
1. 数据库环境说明
（1）说明所采用的数据库系统，设计工具，编程工具等
（2）详细配置
2. 数据库的命名规则
（1）完整并且清楚的说明本数据库的命名规则。
（2）如果本数据库的命名规则与机构的标准不完全一致的话，请作出解释。
3. 逻辑设计
数据库设计人员根据需求文档，创建与数据库相关的那部分实体关系图（ERD）。如果采用面向对象方法（OOAD），这里实体相当于类（class）。
4. 物理设计
（1）主要是设计表结构。一般地，实体对应于表，实体的属性对应于表的列，实体之间的关系成为表的约束。逻辑设计中的实体大部分可以转换成物理设计中的表，但是它们并不一定是一一对应的。
（2）对表结构进行规范化处理（第三范式）。
（3）表汇总
列出表名，功能说明。
每个表的列名，数据类型（精度范围），空/非空，约束条件，补充说明
5. 安全性设计
提高软件系统的安全性应当从“管理”和“设计”两方面着手。这里仅考虑数据库的安全性设计。
5.1 防止用户直接操作数据库的方法
用户只能用账号登陆到应用软件，通过应用软件访问数据库，而没有其它途径操作数据库。
5.2 用户账号密码的加密方法
对用户账号的密码进行加密处理，确保在任何地方都不会出现密码的明文。
5.3 角色与权限
确定每个角色对数据库表的操作权限，如创建、检索、更新、删除等。每个角色拥有刚好能够完成任务的权限，不多也不少。在应用时再为用户分配角色，则每个用户的权限等于他所具有的所有角色的权限。
包括： 角色，可以访问的表与列，操作权限
6. 优化
分析并优化数据库的“时－空”效率，尽可能地“提高处理速度”并且“降低数据占用空间”。
包括：优先级，优化对象（目标），措施
（1）分析“时－空”效率的瓶颈，找出优化对象（目标），并确定优先级。
（2）当优化对象（目标）之间存在对抗时，给出折衷方案。
（3）给出优化的具体措施，例如优化数据库环境参数，对表格进行反规范化处理等。
7. 数据库管理与维护说明
在设计数据库的时候，及时给出管理与维护本数据库的方法，有助于将来撰写出正确完备的用户手册。
5. 用户界面设计
5.1用户界面设计的内容
1. 应当遵循的界面设计规范
结合用户需求和机构的《软件用户界面设计指南》，阐述本软件用户界面设计应当遵循的规范（原则、建议等）。
2. 界面的关系图和工作流程图
（1）给所有界面视图分配唯一的标识符。
（2）绘制各个界面之间的关系图和工作流程图。
3. 主界面
（1）绘制主界面的视图；
（2）说明主界面中所有对象的功能和操作方式；
4. 子界面
（1）绘制子界面的视图；
（2）说明子界面中所有对象的功能和操作方式；
6. 美学设计
（1）阐述界面的布局及理由
（2）阐述界面的色彩及理由
7. 界面资源设计
(1) 图标资源
(2) 图像资源
(3) 界面组件
6 设计过程
6.1 以架构为中心的过程
软件系统的架构是指系统重要组件的组织或结构，这些重要组件通过接口与那些由不断减小的组件与接口所构成的组件进行交互。架构具有以下作用：
1）理解系统使用UML可视化建模系统的架构，并以架构为中心进行开发，这使得开发人员、管理人员及其他相关人员能够详细理解所需要做的工作，以利于他们参与系统的开发。
2）组织开发 架构设计师通过将系统划分为带有明确定义接口的子系统，并让开发小组负责每个子系统，可以显著减少开发组之间交流的工作量，而且接口双方的软件可独立地进化。
3）鼓励重用 好的架构为开发人员提供了可以在其上开展工作的稳定的骨架，它有助于开发人员知道在哪里能有效地找到可重用的元素以及发现合适的可重用的组件。
4）进化系统 一个具有稳定的架构的系统在分析和设计时就考虑到系统进化的需求，从而具有一定的容变能力，系统可以适度地进化。
6.2 迭代和增量开发
迭代（Iteration）是指带有已建立基准（Base Line）的计划和评估准则的独特活动序列，迭代生成系统的内部或外部发布版（Release）。
增量（Increment）是指在后续迭代结束后，两个发布版本之间存在的差异（差值）。一般软件的生命周期是由一系列迭代组成的，这些迭代都是由软件项目分解成的许多袖珍项目（mini-project）。每个迭代都产生以内部版本形式交付的实际结果，其中每个内部版本会增加一个增量并表明所关注的风险得以降低。这些版本可以展示给客户，从而获得有价值的反馈以确认工作成果。早期阶段的迭代主要是关注确定项目的范围，消除关键风险和建立系统架构基准。后期迭代则不断增加增量结果，直至得到一个可对外发布的产品。迭代有助于管理层规划、组织、监控和控制项目。
迭代和增量开发具有以下的一些优点：（1）允许变更需求；（2）允许持续的集成；（3）及早降低风险；（4）有助于组织学习和提高；（5）提高复用性；（6）生成性能更强壮的产品。
6.3 开发规范概述
6.3.1 应用项目开发过程简述
每个项目要根据具体情况拆分成工作阶段，即里程碑，以便对项目进度的有效控制与度量。以项目立项为开始标志。以项目结项为结束标志。
（参考表示）
| 阶段 | 项目计划 | 需求分析 | 系统分析&设计 | 编码实现 | 测试/文档编制 | 验收/发布 | 项目总结 |
| 1 | 项目立项 | 资料收集 | 确定问题域 | 编码规范 | 单元测试 | 项目版本化 | 项目总结 |
| 2 | 立项申请 | 需求分析 | 需求建模 | 单元编码 | 集成测试 | 版本发布 | 任务数度量 |
| 3 | 提交可行性研究报告或系统建设方案 | 需求分析讨论 | 建立分析对象模型 | 编码调试 | 系统测试 | 项目组验收 | 维护计划 |
| 4 | 风险评估 | 需求分析测试/修改 | 系统分析测试/测试后修改 | 单元测试/修改 | 文档编制 | 客户验收 | 输出成果 |
| 5 | 进度计划 | 需求分析评审 | 系统分析评审 | 编码联调 | 开发文档整理 |
| 项目结项 |
| 6 | 提交项目总体计划 |
| 界面设计 | 集成测试/修改 | 用户文档编制 |
|
|
| 7 |
|
| 建立设计模型/设计合并 | 系统测试/修改 | 宣传资料编写 |
|
|
| 8 |
|
| 对象持久化设计 | 编码评审 |
|
|
|
| 9 |
|
| 详细设计 |
|
|
|
|
| 10 |
|
| 系统设计测试/修改 |
|
|
|
|
| 11 |
|
| 系统设计评审 |
|
|
|
|
6.3.2设计阶段的活动
| 序号 | 活动名称 | 角色 | 活动描述 | 备注 |
| 1 | 系统分析 | 架构设计师 | 划分需求的问题域，对每一个问题域进行分析和抽象，定义类和对象的属性与服务，以及结构、静态联系和动态联系。 最终产生面向对象的分析模型。 |
|
| 2 | 架构设计 | 架构设计师 | 建立软件系统的架构，将系统的软件需求分配给软件结构。 架构设计—根据需求，进行分析、设计系统架构，产生架构设计工件。 |
|
| 3 | 架构设计评审 | 架构评审人员 | 检查软件系统架构设计是否合理。 发现和修复缺陷—根据同行评审规范，评审架构设计工件。一致性确认—对架构设计达成一致。 |
|
| 4 | 基线化架构设计 | 配置经理 | 将评审通过的软件架构设计工件置于配置管理。基线化架构一基线化架构设计，作为详细设计的基础。 |
|
| 5 | 软件详细设计 | 设计员 | 根据需求工件架构设计工件，进一步精确描述软件系统，并使之适于具体的实施环境。 详细设计一根据基线化的架构、需求工件，进行详细设计。 |
|
| 6 | 详细设计评审 | 详细设计评审人员 | 检查软件系统详细设计是否合理。 发现和修复缺陷—根据《同行评审规范》，评审详细设计工件。一致性确认—对详细设计达成一致 |
|
| 7 | 基线化详细设计 | 配置管理员 | 将评审通过的软件详细设计工件置于配置管理。 基线化详细设计一对详细设计进行基线化，作为实施活动的基础。 |
|
7. 数据模型设计示例
根据上述问题描述，需要对系统的功能做详细描述，以构造出系统顶层的对象图、状态图和数据流图，
2.2.1 项目内容和功能的输入
（1）项目内容概述（项目具有哪些内容？哪些功能？列出所需的内容和功能的清单。）
（2）项目内容分组和命名（将内容进行分组，也即分成若干个栏目，给每栏起一个名字，中文英文各取一个，中文的用做导航，英文的作为网站文件目录的名字。）
（3）功能需求（列出项目中用户功能性的内容）
2.2.2 项目结构
（1）结构列表
建立一个基于文本形式的项目层次结构图，结构如下：
（2）建立结构蓝图，定义全局和局部导航。
结构蓝图是网站结构的可视化表示，显示网站中的元素如何分组和联系的图表，不同的内容（静态或是动态的）和功能使用不同的几何形状进行表示，整个结构呈现倒树状，内容要素和功能要素使用不同的方法表示。
可用表的示例：
|
| 主线程 | 分线程 | 时间 （天） | 所在分线程时间比 | 所在总线程时间比 |
| 前 台 开 发 | 设计阶段 | 参考 |
|
|
|
| 设计框架 |
|
|
| ||
| 设计装饰图片 |
|
|
| ||
| 完成设计整合 |
|
|
| ||
| 制作阶段 | 设计CSS |
|
|
| |
| 制作框架html |
|
|
| ||
| 加入代码 |
|
|
| ||
| 作代码优化 |
|
|
| ||
| 设计制作 整合 | 与策划人员沟通 |
|
|
| |
| 在后台代码加入后，根据项目小组意见进行整合 |
|
|
| ||
| WEB 服 务 开 发 | WEB 服务层 开发 | 审阅功能规范 |
|
|
|
| 确定模块化/分层设计参数 |
|
|
| ||
| 分派任务 |
|
|
| ||
| 编写代码 |
|
|
| ||
| 开发人员测试（初步调试） |
|
|
| ||
| 上传功能模块 |
|
|
| ||
| 数 据 库 开 发 | 数据库开发 | 审阅功能规范 |
|
|
|
| 确定表/过程设计参数 |
|
|
| ||
| 分派任务 |
|
|
| ||
| 编写代码 |
|
|
| ||
| 开发人员测试（初步调试） |
|
|
| ||
| 上传功能模块 |
|
|
|
2.2.3 备选的分析机制
项目的分析机制还包括
• 永久性
• 安全性
• 分布
• 进程通讯
• 错误报告
• 格式转换
• 消息路由
• 进程控制与同步
• 事务管理
• 信息交换
• 冗余度
2.3 系统的架构机制
架构机制采用MVC(Model-View-Control)，见设计模式，
2.3.1 MVC结构如下图：
2.3.2 定义过程流
然后定义过程流（Process Flow）。
使用UML描述，包括以下内容；
1，描述设计对象的交互
2，使用子系统简化序列图
3，描述永久性相关行为
4，改进事件流描述
输入的用例见附录1表：
2.3.3 对象交互图
对象交互图包括：请求处理序列图，事件处理序列图，使用UML描述。
2.3.4 类设计—从分析类到设计类
从分析类到设计类的过程：可采用如下表（示例）
| 分析类 设计类 说明 |
详细描述：
示例：分析类CreateAccountForm
AccountInfoScreen(帐号信息屏幕)
LoginInfoScreen身份及口令信息屏幕
ReenterEmailScreen(重输邮件地址屏幕)
DuplicateAccountScreen(帐号重复显示屏幕)
2.3.5 数据库设计
需要考虑：
对系统中信息流有严格的顺序关系。
建立强大的查询和统计功能，用户只需要对要查询的数据进行简单的选择和组合即可得到查询结果。
灵活的授权管，用户权限分为三级：超级用户、部门级用户、单据级用户。不同的用户其权限不同。
2.3.6基于Web浏览器的多层结构开发模式
主流的软件架构B/S与N Tier模式都有一些缺点，所以现在出现了许多B－N Tier的系统，就是基于Web浏览器的多层结构开发模式，它吸收了两者的优点。
单纯的B/S方式，虽然可以认为实现了最终用户使用成本几乎为零，但它存在许多不足，它的功能较弱，无法非常容易地实现你的理念。比如你要实现一种商业模型，你会发现实际上Web方式是不安全、不可靠的，比如，用户可通过页面回退或前进来改变你所有希望的结果、报表制作能力不足等（当然这也取决于业务的复杂程度）。
为什么Web会造成逻辑实现上的困难？因为它是基于Stateless（无状态）的，Stateless就是这样一种情形：不知道用户端是什么样子，接收信息是不可控的，不知道传递给他的信息的流向，这就是Stateless。所有基于HTTP的东西都是Stateless的。而Socket的魅力就在于它是有状态的。
现在发展起来的ASP、JSP、Java技术，虽然弥补了HTTP协议存在的无状态缺陷，但即使这些技术再先进，也无法解决HTTP协议基于Stateless的事实。 以基于IIS的ASP技术来说，它使用Session变量来实现State。但是不管什么技术，最终都落在了COOKIE上，也就是使用COOKIE来保留客户端状态。
Socket目前应用十分广泛，ICQ、QQ等即时通讯软件，还有许多网络工具，大都基于Socket，因为Socket协议是有状态的，所以才能做到这一点。可以这么说，是Socket让网络生活更精彩！
目前基于Web的多层结构采用的底层技术主要有SOAP＋State类协议或者HTTP＋State类协议。从Delphi 6开始引入WebSnap包（一种Web Provider产品）。它同时支持HTTP与SOAP协议，也采用了一种类似Session变量的模式来实现有状态(State)。它可以说是目前市面上最强大的基于平台的Browse/Server开发工具之一，不足是它还不能称为完全的RAD工具，且门槛较高。在Delphi 7中还引入了IntraWeb控件包，它是一种真正意义上的网页RAD开发工具，与WebSnap配合更好。
Web Provider、逻辑组件、多线程处理、交易机制、消息流转等组合在一起是N Tier开发的高境界，所以是大型商业软件架构的首选。
另外还需要考虑消息机制，消息机制并不一定在所有的多层结构中都存在，而且，如果要实现消息机制，必须寻找实现手段（比如使用Socket），否则，如果在程序中强制实施大量消息流转（比如使用定时器监控和消息数据表方式），无论是效率还是实现的复杂性来讲都是要考虑的问题。
3. 概要设计
架构设计的描述—概要设计说明
3.1 概要设计的目的
概要设计的目的主要即设计系统架构，包括：
1，将软件系统需求转换为未来系统的设计；
2，逐步开发强壮的系统架构；
3，使设计适合于实施环境，为提高性能而进行设计；
4，结构应该被分解为模块和类。
3.2 概要设计的任务
概要设计的任务包括：
1，制定规范
制订项目组的代码体系、接口规约、命名规则。这是项目小组今后共同作战的基础，有了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法，大家就有了共同的工作语言、共同的工作平台，使整个软件开发工作可以协调有序地进行。
2，总体结构设计
功能（加工）－>模块：每个功能用那些模块实现，保证每个功能都有相应的模块来实现；
模块层次结构：某个角度的软件框架视图；
模块间的调用关系：模块间的接口的总体描述；
模块间的接口：传递的信息及其结构；
处理方式设计：满足功能和性能的算法
3，用户界面设计
（略）
4，数据结构设计
详细的数据结构：表、索引、文件；
算法相关逻辑数据结构及其操作；
上述操作的程序模块说明（在前台？在后台？用视图？用过程？······）
接口控制表的数据结构和使用规则
5，其他性能设计
主要是压力性能的考虑。
3.3 概要设计的原则
总体原则和方法：由粗到细的原则，互相结合的原则，定性分析和定量分析相结合的方法，分解和协调的方法和模型化方法。
要系统考虑系统的一般性、关联性、整体性和层次性。
分解协调：目的是为了创造更好的系统。系统分解是指将一个复杂的系统分解为若干个子系统，系统协调一是系统内协调，即根据系统的总结构、总功能、总任务和总目标的要求，使各个子系统之间互相协调配合，在各个子系统局部优化基础上，通过内部平衡的协调控制，实现系统的整体优化；
屏蔽抽象：从简单的框架开始，隐含细节；
一致性：统一的规范、统一的标准、统一的文件模式；
每个模块应当有一个统一命名的容易理解的名字；
编码：由外向内（界面－>核心）；
面向用户：概要设计是对于按钮按下后系统“怎么做”的简要说明；
模块、组件的充分独立性、封闭性；
同时考虑静态结构与动态运行；
每个逻辑对象都应当说明其所处物理对象（非一一对应）；
每个物理对象都有合适的开发人员，并且利于分工与组装。（详细说明见本人另一篇文章：系统架构设计应考虑的因素）；
确立每个架构视图的整体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口；
软件架构与使用的技术平台密切相关，目前常用的平台有J2EE、.NET、CORBA等等，因此具体的软件架构人员应当具备使用这些平台的软件开发经验；
通过需求功能与设计模块之间的列表对应，检查每个需求功能是否都有相应的模块来实现，保证需求功能的可追溯性和需求实现（模块）的完整性，同时可以检查重复和不必要的模块。
在需求调研分析过程中对业务处理过程了解的完整性和准确性非常重要。调查了解清楚所有的业务流程才能设计出适合各流程业务节点用户业务特点和习惯的软件，使开发出来的软件更受欢迎。当然在进行软件概要设计时，要尽量排除业务流程的制约，即把流程中的各项业务结点工作作为独立的对象，设计成独立的模块，充分考虑他们与其他各种业务对象模块的接口，在流程之间通过业务对象模块的相互调用实现各种业务，这样，在业务流程发生有限的变化时（每个业务模块本身的业务逻辑没有变的情况下），就能够比较方便地修改系统程序模块间的调用关系而实现新的需求。如果这种调用关系被设计成存储在配置库的数据字典里，则连程序代码都不用修改，只需修改数据字典里的模块调用规则即可。
3.4 概要设计的内容
1. 系统概述
(1）说明本系统“是什么”，（2）描述本系统的主要功能。
2. 设计约束
（1）需求约束。体系结构设计人员从需求文档（如《用户需求说明书》和《软件需求规格说明书》）中提取需求约束，例如：本系统应当遵循的标准或规范，软件、硬件环境（包括运行环境和开发环境）的约束，接口/协议的约束，用户界面的约束，软件质量的约束，如正确性、健壮性、可靠性、效率（性能）、易用性、清晰性、安全性、可扩展性、兼容性、可移植性等等。
（2）隐含约束。有一些假设或依赖并没有在需求文档中明确指出，但可能会对系统设计产生影响，设计人员应当尽可能地在此处说明。例如对用户教育程度、计算机技能的一些假设或依赖，对支撑本系统的软件硬件的假设或依赖等。
3. 设计策略
体系结构设计人员根据产品的需求与发展战略，确定设计策略（Design Strategy）。例如：扩展策略。说明为了方便本系统在将来扩展功能，现在有什么措施。复用策略。说明本系统在当前以及将来的复用策略。折衷策略。说明当两个目标难以同时优化时如何折衷，例如“时－空”效率折衷，复杂性与实用性折衷。
4. 系统总体结构
（1）将系统分解为若干子系统，绘制物理图和逻辑图，说明各子系统的主要功能。
（2）说明“如何”以及“为什么”（how and why）如此分解系统。
（3）说明各子系统如何协调工作，从而实现原系统的功能。接口设计：说明外部用户、软、硬件接口；内部模块间接口。
5. 子系统的结构与功能
（1）将子系统分解为模块（Module），绘制逻辑图（如果物理图和逻辑图不一样的话，应当绘制物理图），说明各模块的主要功能。
（2）说明“如何”以及“为什么”（how and why）如此分解子系统N。
（3）说明各模块如何协调工作，从而实现子系统的功能。每个模块“做什么”、简要说明“怎么做”（输入、输出、处理逻辑、与其它模块的接口，与其它系统或硬件的接口），处在什么逻辑位置、物理位置；
6. 开发环境的配置
说明本系统应当在什么样的环境下开发，有什么强制要求和建议？
计算机硬件，软件，网络通信，
7. 运行环境的配置
说明本系统应当在什么样的环境下运行，有什么强制要求和建议？
8. 测试环境的配置
说明本系统应当在什么样的环境下测试，有什么强制要求和建议？
（1）一般地，单元测试、集成测试环境与开发环境相同。
（2）一般地，系统测试、验收测试环境与运行环境相同或相似（更加严格）。
3.5 概要设计的输出
编码规范：信息形式、接口规约、命名规则；
物理模型：组件图、配置图；
不同角度的架构视图：用例视图、逻辑视图、进程视图、部署视图、实施视图、数据视图（可选）；
系统总体布局：哪些部分组成、各部分在物理上、逻辑上的相互关系；
两个不可忽视的输出：
与需求功能的关系：对于需求中的每一个功能，用哪一层、哪个模块、哪个类、哪个对象来实现（一对多关系）；反过来，应当说明将要创建的系统每一层、每个模块、每个对象、每一个类“做什么”，他们是为了帮助实现哪些功能（一对多关系）。（需求的颗粒度在一开始往往是比较粗的，因此根据功能点对于整体项目规模的估计或得到项目WBS其误差范围也是比较大的。更为重要的原因是，需求往往不是编码工作分解的准确依据，因为一个需求的功能点可能对应多个代码模块，而多个需求的功能点也可能只对应一个或少数代码模块，同时还有软件复用等因素要考虑，因此只有在概要设计完成以后才能准确地得到详细设计或编码阶段的二次WBS，并估计较为准确的整体项目规模。）
逻辑与物理位置：每个对象在逻辑上分别落在哪一层、哪个模块、哪个类；在物理上每个模块、每个对象、每一个类放在哪个应用服务器或客户端的哪个目录、哪个文件（库），或者是建立在数据库管理系统中的什么东东（过程、函数、视图、触发器等等）。
4 数据库设计
4.1 数据库设计的内容
1. 数据库环境说明
（1）说明所采用的数据库系统，设计工具，编程工具等
（2）详细配置
2. 数据库的命名规则
（1）完整并且清楚的说明本数据库的命名规则。
（2）如果本数据库的命名规则与机构的标准不完全一致的话，请作出解释。
3. 逻辑设计
数据库设计人员根据需求文档，创建与数据库相关的那部分实体关系图（ERD）。如果采用面向对象方法（OOAD），这里实体相当于类（class）。
4. 物理设计
（1）主要是设计表结构。一般地，实体对应于表，实体的属性对应于表的列，实体之间的关系成为表的约束。逻辑设计中的实体大部分可以转换成物理设计中的表，但是它们并不一定是一一对应的。
（2）对表结构进行规范化处理（第三范式）。
（3）表汇总
列出表名，功能说明。
每个表的列名，数据类型（精度范围），空/非空，约束条件，补充说明
5. 安全性设计
提高软件系统的安全性应当从“管理”和“设计”两方面着手。这里仅考虑数据库的安全性设计。
5.1 防止用户直接操作数据库的方法
用户只能用账号登陆到应用软件，通过应用软件访问数据库，而没有其它途径操作数据库。
5.2 用户账号密码的加密方法
对用户账号的密码进行加密处理，确保在任何地方都不会出现密码的明文。
5.3 角色与权限
确定每个角色对数据库表的操作权限，如创建、检索、更新、删除等。每个角色拥有刚好能够完成任务的权限，不多也不少。在应用时再为用户分配角色，则每个用户的权限等于他所具有的所有角色的权限。
包括： 角色，可以访问的表与列，操作权限
6. 优化
分析并优化数据库的“时－空”效率，尽可能地“提高处理速度”并且“降低数据占用空间”。
包括：优先级，优化对象（目标），措施
（1）分析“时－空”效率的瓶颈，找出优化对象（目标），并确定优先级。
（2）当优化对象（目标）之间存在对抗时，给出折衷方案。
（3）给出优化的具体措施，例如优化数据库环境参数，对表格进行反规范化处理等。
7. 数据库管理与维护说明
在设计数据库的时候，及时给出管理与维护本数据库的方法，有助于将来撰写出正确完备的用户手册。
5. 用户界面设计
5.1用户界面设计的内容
1. 应当遵循的界面设计规范
结合用户需求和机构的《软件用户界面设计指南》，阐述本软件用户界面设计应当遵循的规范（原则、建议等）。
2. 界面的关系图和工作流程图
（1）给所有界面视图分配唯一的标识符。
（2）绘制各个界面之间的关系图和工作流程图。
3. 主界面
（1）绘制主界面的视图；
（2）说明主界面中所有对象的功能和操作方式；
4. 子界面
（1）绘制子界面的视图；
（2）说明子界面中所有对象的功能和操作方式；
6. 美学设计
（1）阐述界面的布局及理由
（2）阐述界面的色彩及理由
7. 界面资源设计
(1) 图标资源
(2) 图像资源
(3) 界面组件
6 设计过程
6.1 以架构为中心的过程
软件系统的架构是指系统重要组件的组织或结构，这些重要组件通过接口与那些由不断减小的组件与接口所构成的组件进行交互。架构具有以下作用：
1）理解系统使用UML可视化建模系统的架构，并以架构为中心进行开发，这使得开发人员、管理人员及其他相关人员能够详细理解所需要做的工作，以利于他们参与系统的开发。
2）组织开发 架构设计师通过将系统划分为带有明确定义接口的子系统，并让开发小组负责每个子系统，可以显著减少开发组之间交流的工作量，而且接口双方的软件可独立地进化。
3）鼓励重用 好的架构为开发人员提供了可以在其上开展工作的稳定的骨架，它有助于开发人员知道在哪里能有效地找到可重用的元素以及发现合适的可重用的组件。
4）进化系统 一个具有稳定的架构的系统在分析和设计时就考虑到系统进化的需求，从而具有一定的容变能力，系统可以适度地进化。
6.2 迭代和增量开发
迭代（Iteration）是指带有已建立基准（Base Line）的计划和评估准则的独特活动序列，迭代生成系统的内部或外部发布版（Release）。
增量（Increment）是指在后续迭代结束后，两个发布版本之间存在的差异（差值）。一般软件的生命周期是由一系列迭代组成的，这些迭代都是由软件项目分解成的许多袖珍项目（mini-project）。每个迭代都产生以内部版本形式交付的实际结果，其中每个内部版本会增加一个增量并表明所关注的风险得以降低。这些版本可以展示给客户，从而获得有价值的反馈以确认工作成果。早期阶段的迭代主要是关注确定项目的范围，消除关键风险和建立系统架构基准。后期迭代则不断增加增量结果，直至得到一个可对外发布的产品。迭代有助于管理层规划、组织、监控和控制项目。
迭代和增量开发具有以下的一些优点：（1）允许变更需求；（2）允许持续的集成；（3）及早降低风险；（4）有助于组织学习和提高；（5）提高复用性；（6）生成性能更强壮的产品。
6.3 开发规范概述
6.3.1 应用项目开发过程简述
每个项目要根据具体情况拆分成工作阶段，即里程碑，以便对项目进度的有效控制与度量。以项目立项为开始标志。以项目结项为结束标志。
（参考表示）
| 阶段 | 项目计划 | 需求分析 | 系统分析&设计 | 编码实现 | 测试/文档编制 | 验收/发布 | 项目总结 |
| 1 | 项目立项 | 资料收集 | 确定问题域 | 编码规范 | 单元测试 | 项目版本化 | 项目总结 |
| 2 | 立项申请 | 需求分析 | 需求建模 | 单元编码 | 集成测试 | 版本发布 | 任务数度量 |
| 3 | 提交可行性研究报告或系统建设方案 | 需求分析讨论 | 建立分析对象模型 | 编码调试 | 系统测试 | 项目组验收 | 维护计划 |
| 4 | 风险评估 | 需求分析测试/修改 | 系统分析测试/测试后修改 | 单元测试/修改 | 文档编制 | 客户验收 | 输出成果 |
| 5 | 进度计划 | 需求分析评审 | 系统分析评审 | 编码联调 | 开发文档整理 |
| 项目结项 |
| 6 | 提交项目总体计划 |
| 界面设计 | 集成测试/修改 | 用户文档编制 |
|
|
| 7 |
|
| 建立设计模型/设计合并 | 系统测试/修改 | 宣传资料编写 |
|
|
| 8 |
|
| 对象持久化设计 | 编码评审 |
|
|
|
| 9 |
|
| 详细设计 |
|
|
|
|
| 10 |
|
| 系统设计测试/修改 |
|
|
|
|
| 11 |
|
| 系统设计评审 |
|
|
|
|
6.3.2设计阶段的活动
| 序号 | 活动名称 | 角色 | 活动描述 | 备注 |
| 1 | 系统分析 | 架构设计师 | 划分需求的问题域，对每一个问题域进行分析和抽象，定义类和对象的属性与服务，以及结构、静态联系和动态联系。 最终产生面向对象的分析模型。 |
|
| 2 | 架构设计 | 架构设计师 | 建立软件系统的架构，将系统的软件需求分配给软件结构。 架构设计—根据需求，进行分析、设计系统架构，产生架构设计工件。 |
|
| 3 | 架构设计评审 | 架构评审人员 | 检查软件系统架构设计是否合理。 发现和修复缺陷—根据同行评审规范，评审架构设计工件。一致性确认—对架构设计达成一致。 |
|
| 4 | 基线化架构设计 | 配置经理 | 将评审通过的软件架构设计工件置于配置管理。基线化架构一基线化架构设计，作为详细设计的基础。 |
|
| 5 | 软件详细设计 | 设计员 | 根据需求工件架构设计工件，进一步精确描述软件系统，并使之适于具体的实施环境。 详细设计一根据基线化的架构、需求工件，进行详细设计。 |
|
| 6 | 详细设计评审 | 详细设计评审人员 | 检查软件系统详细设计是否合理。 发现和修复缺陷—根据《同行评审规范》，评审详细设计工件。一致性确认—对详细设计达成一致 |
|
| 7 | 基线化详细设计 | 配置管理员 | 将评审通过的软件详细设计工件置于配置管理。 基线化详细设计一对详细设计进行基线化，作为实施活动的基础。 |
|
7. 数据模型设计示例
725
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
