地理信息系统概要设计说明书
河南环保厅环境地理信息系统概要设计说明书
上海数慧系统技术有限公司
Shanghai Digital Intelligence Systems Technology Co., Ltd.
请保护环境，注意纸张的回收利用
版权信息
本文件涉及之信息，属上海数慧系统技术有限公司所有。
未经上海数慧系统技术有限公司允许，文件中的任何部分都不能以任何形式向第三方散发。
上海数慧系统技术有限公司完全拥有知识产权，并受国际知识产权法律保护。
目录
第1章.引言 (5)
1.1.目的 (5)
1.2.文档概述 (5)
1.3.术语定义 (5)
1.4.参考资料 (6)
第2章.系统概述 (6)
2.1.系统开发背景 (7)
2.2.建设目标 (7)
2.3.约束条件与非功能需求 (8)
2.3.1.开发环境要求 (8)
2.3.2.软件系统架构要求 (8)
2.3.3.性能要求 (8)
2.3.4.质量需求 (9)
2.4.用户 (9)
2.4.1.组织机构 (9)
2.4.2.用户分类 (9)
第3章.概念架构设计 (10)
3.1.系统划分 (10)
3.2.系统架构 (10)
3.3.概念架构 (11)
3.3.1.B/S系统概念架构 (11)
3.3.2.C/S系统概念架构 (13)
第4章.细化架构设计 (14)
4.1.逻辑架构 (14)
4.1.1.B/S架构 (15)
4.1.2.C/S架构模式 (20)
4.2.开发架构 (20)
4.2.1.技术路线 (21)
4.2.2.B/S浏览器端开发视图 (22)
4.2.3.B/S服务端开发视图 (23)
4.2.4.C/S架构开发视图 (24)
4.3.运行架构 (27)
4.3.1.系统启动时序图 (27)
4.3.2.河流污染扩散模型时序图 (28)
4.4.数据架构 (30)
4.5.部署架构 (31)
4.5.1.系统部署架构 (31)
4.5.2.部署设计 (32)
4.5.3.网络和硬件配置 (33)
4.5.4.软件配置 (34)
第5章.系统对外接口 (35)
5.1.客户端地图组件接口 (35)
5.1.1.组件嵌入方法 (36)
5.1.2.已有接口方法 (37)
5.2.业务逻辑层W EB S ERIVCES服务接口 (44)
5.2.1.地图查询接口 (44)
5.2.2.点位编辑接口 (45)
第1章.引言
1.1.目的
编写目的：本说明书是在《河南省环境保护厅环境地理信息系统投标方案》、《河南省环境保护厅环境地理信息系统需求分析说明书》的基础之上，经过分析和系统设计编写而成。用于将软件系统需求转换为未来系统的设计，逐步开发强壮的系统构架，使设计适合于实施环境，为提高性能而进行的设计工作，对后面的概要设计、编码实现、测试、部署实施、运行维护工作有着关键性的影响。
适用读者：河南省环境保护厅项目组成员
数慧公司项目组成员
1.2.文档概述
本说明书包括引言、系统概述、总体设计、功能设计、接口设计、数据结构设计、出错处理设计、系统部署设计等，以提供关于程序系统的逻辑和数据功能实现方式的总体描述。
1.3.术语定义
OGC：开放地理信息系统协会(OpenGISConsortium,OGC),OpenGIS规范致力于为地理信息系统间的数据和服务互操作提供统一。
W3C：是对网络标准制定的一个非赢利组织，像HTML、XHTML、CSS、XML 的标准就是由W3C来定制。W3C会员（大约500名会员）包括生产技术
产品及服务的厂商、内容供应商、团体用户、研究实验室、标准制定机
构和政府部门，一起协同工作，致力在万维网发展方向上达成共识。
SOA：面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服
务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定
义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使
得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交
互。
Web service：是创建可互操作的分布式应用程序的新平台。Web service 的主要目标是跨平台的可互操作性。为了达到这一目标，Web service 是
完全基于XML、XSD等独立于平台、独立于软件供应商的标准的。
REST（Representational State Transfer）是一种轻量级的Web Service 架构风格，其实现和操作明显比SOAP和XML-RPC更为简洁，可以完全通
过HTTP协议实现，还可以利用缓存Cache来提高响应速度，性能、效率
和易用性上都优于SOAP协议。
SOAP（Simple Object Access Protocol），它是一种标准消息传递协议，通常是Web Service的事实标准。SOAP是以XML为基础，SOAP消息格式
是由XML Schema模式定义，通过XML命名空间使SOAP具有很强的扩展
性。
WMS：Web地图服务（WMS）利用具有地理空间位臵信息的数据制作地图。
其中将地图定义为地理数据可视的表现。
WFS：Web地图服务返回的是图层级的地图影像，Web要素服务（WFS）返回的是要素级的GML编码，并提供对要素的增加、修改、删除等事务操
作，是对Web地图服务的进一步深入。
WCS：Web覆盖服务（WCS）面向空间影像数据，它将包含地理位臵值的地理空间数据作为“覆盖（Coverage）”在网上相互交换。
ESB：企业服务总线（Enterprise Service Bus）：传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构
筑企业神经系统的必要元素。基本功能为动态查找与路由、消息聚合与
分发、消息转换、数据绑定转换。
1.4.参考资料
《河南省环境保护厅环境地理信息系统投标方案》
《河南省环境保护厅环境地理信息系统需求分析说明书》
《软件架构设计》
《SOA 原理.方法.实践》
《SOA整合之道》
《企业应用架构模式》
《WEB 服务架构与开放互操作技术》
第2章.系统概述
2.1.系统开发背景
河南省近年来高度重视环境保护工作，坚持以污染防治为重点，以改善重点流域、重点区域环境质量为主线，不断加大环境保护力度。到2009年底河南省将建成覆盖全省的多个环境环境自动监控系统。此大规模自动监控系统建设，迫切需要一个统一的建设规范和标准，约束改造和代建的新系统。因此，有必要建设地理信息系统，实现环境自动监控数据的空间表达，充分发挥最新通讯技术、信息技术、数据库技术、空间技术的优势，为河南省环境保护的管理、评价、决策工作提供有效支持。
2.2.建设目标
河南省建立环境地理信息系统，以充分发挥全省的环境质量、污染源自动监控系统的作用，形象展示环境自动监控数据，为河南省的环境信息化坚实打下坚实的基础，为各级环保部门的环境管理、决策服务。
具体目标如下：
建设满足省环保厅业务应用的基础地理空间数据库，数字影像数据库，环保专业专题数据库。
建设面向省环保厅业务应用的地理信息平台，满足环保业务对空间信息辅助决策支持应用的需求。
以基础地理空间数据库为依托，GIS能够为污染源在线自动监控系统、环境质量管理系统、移动监察与执法系统、环境应急决策支持系统、数
据中心和综合分析系统等提供基本的电子地图和专题地图，实现空间信
息、属性信息的双向查询以及空间分析服务。基于SOA
（Service-Oriented Architecture，面向服务的架构），实现GIS Web
Service与其它子系统的集成，并通过GIS发布功能为决策提供支持服
务。
提供C/S方式的环境地理信息编辑管理发布系统，基于WEB方式的环境地理信息查询分析系统，可进行环境专题图制作与输出、查询统计汇总。
实现空气污染扩散、水污染扩散模拟展示。实现重点监控目标三维展示。
基于环境地理信息系统，在大屏幕上实时、近实时展现环境、企业、污染物变化等信息。
2.3.约束条件与非功能需求
根据需求调研阶段的成果，本系统的约束条件包括软件开发环境要求，系统架构需求和性能需求几部分
2.3.1.开发环境要求
系统需要在Oracle 11g数据库管理软件，ArcGIS Server 9.3地理信息系统软件的基础环境下进行开发建设。
2.3.2.软件系统架构要求
系统采用组件式开发方式，针对普通用户（包括公众用户）的功能采用B/S 模式开发，针对管理用户的功能采用C/S模式开发，系统应采用分布式B/S三层架构的方式进行开发。
要求功能菜单、发布内容可用户定制，可根据数据情况进行动态关联，特别是针对新增表及表字段，可发布、可计算、可加工、可制作等。
本系统要求采用SOA系统架构，提供良好的可扩展性和容错性，采用Web Service技术。
本系统的客户展现端要求支持多种操作系统。
2.3.3.性能要求
一般操作响应时间应不超过1秒
按图上信息检索调图时，每次调图时间不大于5秒；
其他复杂操作最多不超过10秒；
本项目面向的用户包括河南省环境保护厅及各省辖市相关业务用户。系统应当支持的用户数规模为500个。
允许并发操作用户数大于50；
2.3.4.质量需求
以系统连续运行120小时以上系统无错误发生进行衡量；
2.4.用户
2.4.1.组织机构
本系统服务的机构从里到外分别是环保厅内部各职能部门、下属各市环保局、其它委办局，现阶段主要考虑的用户主要是环保厅内部各职能部门。
2.4.2.用户分类
专题业务用户：包括环保厅内部相关业务部门，使用地理信息系统模块的其他系统。可以进入专题应用系统，使用专题功能。
数据管理员：空间数据入库、更新、编辑、地图文件管理。
系统管理员：服务注册、发布、地图服务管理、目录管理、权限分配，地图管理，日常维护。
第3章.概念架构设计
3.1.系统划分
根据项目合同，招标文件和需求分析说明书，本系统需要实现的主要功能包括：
地理数据处理、数据质检、空间数据库管理
环境地理信息数据展示、业务应用功能、对外服务
地图服务注册、管理，系统服务管理
系统用户、角色、权限、日志等日常管理
根据系统功能和职责划分的原则，把系统分为如下子系统：
数据规整与建库、空间数据库管理系统子系统；环境空间信息综合展示系统子系统和综合应用子系统；服务调度管理子系统和运行维护管理子系统，如图3-1所示。
图3-1系统划分图
3.2.系统架构
系统的技术路线和架构模式，需要根据项目功能需求和性能需求，质量属性等非功能的需求、约束条件，综合考虑，因事制宜，才能满足项目的要求。
根据上文阐述，根据功能需求把系统划分为四个子系统。环境空间信息综合展示子系统是本系统的主要对外部分，提供给厅内各个部门业务办公使用，需要尽量简便的客户段部署，方便用户使用；同时还要向环境自动监控、数据中心、应急响应系统等大量B/S架构的系统提供电子地图，空间信息查询等服务，所以适宜使用B/S技术架构。而空间数据管理子系统、运行维护管理子系统、服务调图管理子系统面向的用户为监控中心管理员，使用涉众较少，再者，对于复杂的空间数据入库，编辑管理，后台服务调度和运维管理，需要强调高效，实时性和可交互性。更适合C/S的架构方案。
针对B/S的地理信息系统，采用分层架构模式是实现系统模块化的主流思想，该模式是为细化需求，降低模块间耦合，提高复用度而逐渐形成的应用系统标准模式。此方法以传统的多层架构（至上而下为展现层、逻辑层、持久层）为基础，对整个软件系统的设计进行分解。
结合关键用例，以及质量属性与系统约束，涉及到架构的可复用性、可扩展性、易开发与维护性，并且在基于高效稳定的前提下，在系统的架构分层中提出服务层概念，包括基础服务层和数据服务层。所谓服务层，是指将技术支撑子系统与模块单独隔离，以服务的方式提供给更高层的应用逻辑层访问，从而使得系统的开发更关注与业务逻辑的编排与组织。从设计原则上来讲，业务逻辑属于变化的范畴，而对于技术层面来讲相对稳定。因此将变化的部分有效隔离，完全符合面向对象设计思想的原理。
因此，整个系统的概念性架构的模式可以定位为：采用B/S分层架构与C/S 架构系统的综合运用。在环境空间信息综合展示子系统采用B/S分层模式，而空间数据管理子系统、运行维护管理子系统、服务调图管理子系统，将采用C/S 架构。
3.3.概念架构
3.3.1.B/S系统概念架构
B/S架构采用分层架构模式，可在概念上把整个系统划分为表现层、业务层服务层、基础服务层和数据资源层。如图3-2所示，以以“断面信息查询”用例
为例，说明了该用例鲁棒图所涉及的各种类在分层架构上的分布情况。
图3-2 B/S系统概念架构图
各层级的主要职责如下：
数据资源层：主要完成数据的分类存贮，数据库分为四个类：基础地理数据库：存放基础地形数据，包括各种比例尺的矢量数据、DEM数据、影像数据。元数据库：存放空间数据的元数据信息，包括目录结构、编目信息、层字段信息、坐标信息、生产日期。业务数据库：各种业务专题数据，如污染普查数据、环境统计数据。这些数据库是以分布的形式部署在环保局各个部门中，不必都放在信息中心。系统数据库：存放安全信息、配臵信息、日志信息。
基础服务层：提供数据访问，地图访问服务。本系统的的基础服务层由基础
构件和第三方构件组成。数据访问服务：完成各种数据库访问，以及非结构化数据如文件数据的访问。各类地图服务的提供，如地图访问，地图运算等。
业务逻辑层：负责数据查询，分析运算，统计等与业务紧密相关的功能。
应用层:负责数据资源的展现、发布、专题应用。环境信息综合展示：负责空间数据的浏览、查询，图层管理等基本GIS操作，以及统计，专题图输出，大气污染扩散模型，水污染扩散模型，三维系统等功能。专题应用模块：专题应用模块：提供各类专题业务系统电子地图，提供空间信息和属性信息的互查等。如在线监测系统、环统应急系统，数据中心系统。
3.3.2.C/S系统概念架构
C/S架构采用传统的MVC设计模式，把系统分为表现层，业务层，持久层三层。如图3-3所示，以以“数据入库”用例为例，说明了该用例鲁棒图所涉及的各种类在分层架构上的分布情况。
图3-3 C/S系统概念架构图
第4章.细化架构设计
细化架构也称作具体架构，它将以概念架构为基础，参照其架构模式，结合非功能性需求的“需求-场景-决策表”，分不同视角展开讨论。细化架构可采用Rational公司推介的“4+1”视图，采用“5视图法”，两者在理念上并无太大的分别，但“5视图法”在实践上更易于理解，因此本文将采用“5视图法”，把细化架构划分为逻辑架构、开发架构、运行架构、数据架构和部署架构等五个视图，如图5-1所示。其中逻辑、部署以及运行视图是决定系统架构的主要因素。细化架构通常以逻辑架构为核心，以开发架构为结果。
该架构包含B/S与C/S两种模式。B/S与C/S架构需要依赖共同的组件，但是在架构上有一定差别。在后面章节分别论述。
图4-1 系统细化架构的5个视图
4.1.逻辑架构
在分层架构的基础上，得到如图4-2所示的细化逻辑架构。该架构分为B/S 与C/S两个部分。B/S架构分为数据访问层、地图服务层、业务逻辑层以及界面
展现层。C/S部分分为界面展现层，地图服务层和底层平台。下面逐一描述各个层次的职责以及其交互机制。
图5-2 系统逻辑架构
4.1.1. B/S架构
4.1.1.1.数据访问层
数据访问层是基础服务层的一部分，主要包括数据引擎、ArcObject对象访问服务、文件服务及XML框架，共四大模块，其相互间逻辑关系如图4-3所示。各个模块的主要职责为：
数据引擎主要用于对数据存取的操作，为整个系统提供统一的数据交互入口以及事务处理服务，属于该层的核心模块；
ArcObject对象访问服务主要用于访问地理数据，为整个系统提供读写，编辑地理数据的服务，属于该层的核心模块；
XML服务的作用主要用于对业务元数据以及系统配臵文件的读写操作，优化文件访问的性能；
文件服务模块主要用于对本地或者远程文件的访问操作。它套用了适配器设计模式(adapter pattern)，屏蔽了不同访问方式之间的差异性，并
提供可扩展的数据访问接口，以满足日后的不同文件访问方式——如通
过网络二进制数据流直接构造文本文件等；
图4-3 数据访问层架构
4.1.1.2.地图服务层
地图服务层是基础服务层的一部分，指用于支持业务运行的地图服务和地理运算服务，如图4-4所示。
图5-4 地图服务层的逻辑架构
本层由第三方应用构件组成，主要是ArcGISServer服务。这里需要说明的是：在本文中，所谓构件，是指实现相应接口契约、独立组织的、自治的功能单元。构件的运行一般需要相应的软件基础设施来提供环境，通过加载到相应的运行框架或者子系统来激活，因此，对于服务层的各个构件模块，相互之间可没有直接的依赖关系。
4.1.1.3.业务逻辑层
应用逻辑层是系统的核心部分，由业务服务和系统服务两部分组成，它们都要调用基础服务层的数据访问构件。如图4-5所示。
图4-5 应用逻辑层的逻辑架构
其中，业务服务由统计分析服务，智能搜索服务，图形查询服务，图形编辑服务，元数据服务，数据字典服务等功能组成。如图4-6所示。
图4-6 业务服务部分的逻辑架构
而系统服务端由界面管理服务，系统日志服务，系统异常服务，系统权限服
务等组成，如图4-7所示。
图4-7系统服务部分的逻辑架构
4.1.1.4. 界面展现层
界面展现层主要通过界面框架，将业务功能，界面布局，后台服务，消息、资源等组织起来。功能以插件形式进行加载，而加载控制和服务的访问控制由前台框架和后台服务共同完成。其逻辑结构如图5-9所示。
图4-8 界面展现层的逻辑架构
4.1.2. C/S架构模式
4.1.2.1.C/S逻辑架构
需要CS架构的系统包括：空间数据库管理系统，运行维护管理系统，服务调图管理系统。这三个系统采用数慧DGP3.2平台，作为其基础服务支撑。
图4-9 C/S模式的逻辑架构
4.2.开发架构
B/S架构系统开发工具使用J2EE平台以及Flex Builder开发工具。
C/S架构系统开发工具microsoft visual studio以及.net framework SDK。
图4-10 列出开发架构的核心工程：
概要设计说明书范例及模板
《XXXXXX》概要设计说明书 张三、李四、王五
1．引言 1．1编写目的 在本机票预定系统项目的前一阶段，也就是需求分析阶段中，已经将系统用户对本系统的需求做了详细的阐述，这些用户需求已经在上一阶段中对航空公司、各旅行社及机场的实地调研中获得，并在需求规格说明书中得到详尽得叙述及阐明。 本阶段已在系统的需求分析的基础上，对机票预定系统做概要设计。主要解决了实现该系统需求的程序模块设计问题。包括如何把该系统划分成若干个模块、决定各个模块之间的接口、模块之间传递的信息，以及数据结构、模块结构的设计等。在以下的概要设计报告中将对在本阶段中对系统所做的所有概要设计进行详细的说明。 在下一阶段的详细设计中，程序设计员可参考此概要设计报告，在概要设计对机票预定系统所做的模块结构设计的基础上，对系统进行详细设计。在以后的软件测试以及软件维护阶段也可参考此说明书，以便于了解在概要设计过程中所完成的各模块设计结构，或在修改时找出在本阶段设计的不足或错误。 1．2项目背景 机票预定系统将由两部分组成：置于个旅行社定票点的前台客户程序，以及置于航空公司的数据库服务器。本系统与其他系统的关系如下： 1．3定义 1．3．1 专门术语 SQL SERVER: 系统服务器所使用的数据库管理系统（DBMS）。 SQL: 一种用于访问查询数据库的语言 事务流：数据进入模块后可能有多种路径进行处理。 主键：数据库表中的关键域。值互不相同。 外部主键：数据库表中与其他表主键关联的域。 ROLLBACK: 数据库的错误恢复机制。 1．3．2 缩写
系统：若未特别指出，统指本机票预定系统。 SQL: Structured Query Language（结构化查询语言）。 ATM: Asynchronous Transfer Mode (异步传输模式)。 1．4参考资料 以下列出在概要设计过程中所使用到的有关资料： 1．机票预定系统项目计划任务书浙江航空公司1999/3 2．机票预定系统项目开发计划《**》软件开发小组1999/3 3．需求规格说明书《**》软件开发小组1999/3 4．用户操作手册（初稿）《**》软件开发小组1999/4 5．软件工程及其应用周苏、王文等天津科学技术出版社1992/1 6．软件工程张海藩清华大学出版社1990/11 7．Computer Network A.S.Tanenbaun Prentice Hall 1996/01 文档所采用的标准是参照《软件工程导论》沈美明著的“计算机软件开发文档编写指南”。 2．任务概述 2．1 目标 2．2 运行环境 系统将由两部分程序组成，安装在各旅行社客户机上的客户程序及航空公司内的数据服务器程序。 根据调研得知所有旅行社的计算机配置均在Pentium 133级别以上，客户程序应能够在Pentium 133级别以上, Win NT环境下运行。 2．3 需求概述 浙江航空公司为方便旅客，需开发一个机票预定系统。为便于旅客由旅行社代替航空公司负责为旅客定票，旅行社把预定机票的旅客信息，包括姓名、性别、工作单位、身份证号码、旅行时间、旅行目的地，输入机票预定系统的客户端程序，系统经过查询航空公司内的航班数据服务器后，为旅客安排航班，印出取票通知。旅客在飞机起飞前一天凭取票通知和帐单交款后取票，系统校对无误后即印出机票给旅客。 要求系统能有效、快速、安全、可靠和无误的完成上述操作。并要求客户机的界面要简单明了，易于操作，服务器程序利于维护。 2．4 条件与限制 3．总体设计 3．1 处理流程 下面将使用（结构化设计）面向数据流的方法对机票预定系统的处理流程进行分
软件项目概要设计说明书
实验报告 学院：计算机与星系学院专业：软件工程年级：08级 姓名：陈世煌学号：081181059 实验室号：312 计算机号：59 实验日期：2011 年10 月 6 日指导教师签字：成绩： 报告退发(订正、重做) 电子商务概要设计说明书 1.引言 1．编写目的 Web技术高速发展，已经到了Web2.0时代，出现了很多新的技术和工具，主要包括：博客（BLOG）、RSS、百科全书(Wiki)、网摘、社会网络（SNS）、P2P、即时信息（IM）等技术，这些工具和技术的出现，使得人们从原来Web1.0时代作 为个人只能看Web内容过渡到了不仅是内容的浏览者，同时也是内容的发布者， 人们的交流越来越容易，而在国内博客这一Web2.0工具应用的非常广泛，已经深 入到网络的每个角落。 2．项目背景 电子商务系统，是指使用计算机语言编写，并便于用户安装和使用，在互联网上建立电子商务的一整套系统。网上商品通常根据张贴时间，以倒序方式由新到旧 排列。许多博客专注在特定的课题上提供评论或新闻，其他则被作为比较个人的日 记。一个典型的电子商务结合了文字、图像、其他网站的链接、及其它与主题相关 的媒体。能够让读者以互动的方式留下意见，是许多博客的重要要素。博客是社会 媒体网络的一部分。介于商务的实用性与应用广泛的特点，项目决定实现一款具备 基本功能的电子商务系统。 3．定义 专门术语 缩写
4．参考资料 2.任务概述 1．目标 2．运行环境 中间件服务器Tomcat6.026 JDK版本JDK1.6 数据库mysql 3．需求概述 作为互联网战略的延伸，电子商务的热潮一度兴起，但是一直以来，很多企业网站都局限在信息发布等一些基本的功能，而越来越深入的实践表明，这些仅仅代表了企业网站的一个起点功能。随着企业网络环境的发展成熟，企业门户网站可以帮助企业把现有的业务系统整合起来，集中优势资源为客户提供个性化服务，并为企业创建一个良好的收入渠道。 2.4条件与限制 ●资金、时间约束：无 ●技术约束：采用C/S结构，数据库采用SQL SERVER，界面要求使用汉字。 ●标准约束：《编程规范》，《界面风格规范》 3.总体设计 1．处理流程
概要设计说明书实例
1 引言 (3) 1.1 编写目的 (3) 1.2 背景 (3) 1.3 定义 (3) 1.4 参考资料 (3) 2 总体设计 (3) 2.1 简述 (3) 2.2 架构设计 (4) 2.2.1 系统逻辑架构图 (4) 2.2.2 系统物理架构图 (4) 2.2.3 顶层系统包图 (5) 2.2.4 业务类包图 (6) 2.2.5 子系统关系图 (6) 2.3 接口设计 (6) 2.3.1 界面框架设计 (6) 2.3.2 外部接口设计 (7) 3 子系统设计 (7) 3.1 基础信息子系统 (7) 3.1.1 子系统说明 (7) 3.1.2 类图 (8) 3.1.3 类说明 (12) 3.1.4 界面设计 (19) 3.2 我的工作台子系统 (21) 3.2.1 子系统说明 (21) 3.2.2 类图 (22) 3.2.3 类说明 (26) 3.2.4 界面设计 (32) 3.3 工作进展子系统 (33) 3.3.1 子系统说明 (33) 3.3.2 类图 (34) 3.3.3 类说明 (34) 3.3.4 界面设计 (34) 3.4 信息发布子系统 (36) 3.4.1 子系统说明 (36) 3.4.2 类图 (36) 3.4.3 类说明 (37) 3.4.4 界面设计 (38) 3.5 系统管理子系统 (38) 3.5.1 子系统说明 (38) 3.5.2 类图 (39) 3.5.3 类说明 (39) 3.5.4 界面设计 (40) 3.6 个人设置子系统 (41)
3.6.1 子系统说明 (41) 3.6.2 类图 (42) 3.6.3 类说明 (43) 3.6.4 界面设计 (44) 4 约束和假定 (45) 5 系统数据结构设计 (45) 5.1 逻辑结构设计 (45) 5.1.1 角色表（PUBLIC_ROLE） (46) 5.1.2 权限表（PUBLIC_PRIVILEGE） (46) 5.1.3 角色权限表（PUBLIC_ROLEPRIVILEGE） (46) 5.1.4 部门表（PUBLIC_ DEPT） (46) 5.1.5 岗位表（PUBLIC_POST） (47) 5.1.6 员工表（PUBLIC_MEMBER） (47) 5.1.7 工作任务表（WORKPLAN_ TASK） (48) 5.1.8 任务分派表（WORKPLAN_ ALLOTTASK） (48) 5.1.9 工作计划表（WORKPLAN_ PLAN） (48) 5.1.10 计划任务表（WORKPLAN_ PLANTASK） (49) 5.1.11 工作日志表（WORKPLAN_ WORKLOG） (49) 5.1.12 工作汇报表（WORKPLAN_ WORKREPORT） (50) 5.1.13 信息发布表（PUBLIC_ PUBLISHINFO） (50) 5.1.14 收件箱表（PUBLIC_INBOX） (50) 5.1.15 系统操作日志表（PUBLIC_OPERA TELOG） (51) 5.1.16 个人提醒设置表（PUBLIC_EVENTS） (51) 5.1.17 系统表（PUBLIC_SYSTEM） (52) 5.1.18 系统功能模块表（PUBLIC_SYSTEMMODULE） (52) 5.2 物理结构设计 (52) 5.3 数据结构与程序的关系 (52) 6 系统出错处理设计 (52) 6.1 出错信息 (52) 6.2 补救措施 (53) 6.3 系统维护设计 (53)
(完整版)博客系统需求分析
校园博客系统需求分析 评审日期：2010 年04 月01 日 目录 1导言 (1)
1.2范围 (1) 1.3缩写说明 (1) 1.4术语定义 (1) 1.5引用标准 (1) 1.6参考资料 (2) 2系统定义 (2) 2.1项目来源及背景 (2) 2.2系统整体结构 (2) 3应用环境 (3) 3.1系统运行网络环境 (3) 3.2系统运行硬件环境 (4) 3.3系统运行软件环境 (4) 4功能规格 (4) 4.1角色（ A CTOR ）定义 (5) 4.1.1博客访问者 (5) 4.1.2管理用户 (5) 4.1.3 数据库 (6) 4.2系统主U SE C ASE图. (6) 4.3客户端子系统 (6) 4.4管理端子系统 (8) 4.4.1 登录管理 ....................................................... 10 4.4.2 类型管理 ......................................................... 11 4.4.3 评论管理 ....................................................... 12 4.4.4 留言管理 ....................................................... 12 4.4.5 图片管理 ....................................................... 12 4.4.6 用户管理 ....................................................... 13 5性能需求 (13) 5.1 界面需求 (13) 5.2响应时间需求 (13) 5.3可靠性需求 (13) 5.4开放性需求 (14) 5.5可扩展性需求 (14) 5.6系统安全性需求 (14) 6产品提交 (14)
系统概要设计说明书规范
KTV点歌系统概要设计说明书
1. 引言 1.1目的 选歌系统是为某KTV唱吧开发的视频歌曲点唱软件。该软件能方便顾客进行选歌，帮助系统管理员管理歌曲的播放，提高KTV歌曲点唱的效率和准确率。 本文档为该系统的概要设计说明书，详细阐述了对用户所提出需求的设计方案，对系统中的各项功能需求、技术需求、实现环境及所使用的实现技术进行了明确定义。同时，对软件应具有的功能和性能及其他有效性需求也进行了定义。 1.2项目背景 ●系统名称：选歌系统 ●项目提出者：某KTV唱吧 ●项目开发者： ●项目管理者： ●最终用户：某KTV唱吧 1.3术语定义 实现环境：系统运行的目标软件、硬件环境。 实现技术：系统所采用的软件技术或体系结构。 实现语言或工具：实现系统最终采用的编程语言或工具包，如Delphi、VB、PB、Java、Ada等。 参考资料 1)新余电视点播系统； 2)某KTV唱吧《视频点歌系统计划任务书》； 本项目所参照的文件有： 3)康博工作室，《Visual Basic 新起点》，机械工业出版社，2000
2. 系统概述 2.1系统需求 2.1.1系统目标 本软件是为某KTV唱吧开发的视频点歌系统软件。该软件用于提高点歌系统的工作效率。随着人们业余生活的丰富，休闲活动的多种多样，人们更多的喜欢选择KTV这种形式的娱乐方式。且随着计算机普及，点歌系统越来越智能化，人性化；一个好的音乐唱吧必须要拥有一个方便、快捷、准确的点歌系统，因此，急需一个软件系统解决这些问题。本软件应能结合当前选歌播放手工操作的流程以及将来业务发展的需要，对视频点歌系统中歌曲信息、歌手信息、最新排行榜等等的查询、更新提供完全的计算机管理。 2.1.2性能需求 数据精确度 数量值：精确到小数后一位； 时间值：精确到日，并以yyyy/mm/dd的形式表示； 价格值：精确到分，并以.XX的形式表示。 时间特性 页面响应时间：不超过10秒 更新处理时间：不超过15秒 数据转换与传输时间：不超过30秒。 适应性 1) 开发基于的平台要考虑向上兼容性，如操作系统，数据库等要考虑更高版本的兼容 性。 2) 当需求发生变化时系统应具有一定的适应能力，要求系统能够为将来的变更提供以 下支持：能够在系统变更用户界面和数据库设计，甚至在更换新的DBMS后，系统的现有设计和编码能够最大程度的重用，以保护现阶段的投资和保证软件系统能够在较少后续投入的情况下适应系统的扩展和更新。在设计中最好列出针对变更所需要重新设计的模块部分
软件概要设计说明书模版
软件概要设计报告文档模板 1. 引言 (2) 1.1编写目的 (2) 1.2项目风险 (2) 1.3预期读者和阅读建议 (2) 1.4参考资料 (2) 2. 设计概述 (3) 2.1限制和约束 (3) 2.2设计原则和设计要求 (3) 3. 系统逻辑设计 (4) 3.1系统组织设计 (4) 3.2系统结构设计 (4) 3.2.1 系统特性表 (5) 3.2.2 系统特性结构图 (6) 3.3系统接口设计 (6) 3.3.1 系统接口表 (6) 3.3.2 系统接口传输协议说明 (7) 3.4系统完整性设计 (7) 4. 系统出错处理设计 (8) 4.1系统出错处理表 (8) 4.2维护处理过程表 (9) 5. 技术设计 (10) 5.1系统开发技术说明表 (10) 5.2开发技术应用说明 (11) 6. 数据库设计 (11) 7. 词汇表 (11) 8. 进度计划 (11)
1. 引言 引言是对这份软件系统概要设计报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件系统概要设计报告是基于哪份软件产品需求规格说明书编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件系统概要设计报告详尽说明了该软件产品的软件结构，包括数据库结构和出错处理，从而对该软件产品的结构的描述。 如果这份软件系统概要设计报告只与整个系统的某一部分有关系，那么只定义软件系统概要设计报告中说明的那个部分或子系统。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者； ●软件开发者； ●产品使用者。 1.3 预期读者和阅读建议 列举本软件系统概要设计报告所针对的各种不同的预期读者，例如，可能的读者包括： ●用户； ●开发人员； ●项目经理； ●营销人员； ●测试人员； ●文档编写人员； ●等等。 描述文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。 1.4 参考资料 列举编写软件产品概要设计报告时所用到的参考文献及资料，可能包括： ●本项目的合同书； ●上级机关有关本项目的批文； ●本项目已经批准的计划任务书； ●用户界面风格指导；
软件概要设计说明书范例
XX概要设计说明书
文档修改记录
填写说明 1. 系统结构的定义 本体系对整个软件系统按如下结构方式进行划分：系统子系统模块子模块 其中： （1）“系统子系统”划分属于“系统设计”，在系统设计说明书中予以描述。 （2）“子系统模块”划分属于“概要设计”，在本说明书中予以描述。 （3）“模块子模块”划分属于“详细设计”，在详细设计说明书中予以描述。如果系统相对简单，可以省略“子模块”这一层次。 2. 如果填写了系统设计说明书，则在本说明书中略过“系统子系统”划分的相关内容（即第2章）。 3. 如果系统相对简单，不需要做“系统子系统”划分，这种情况下，取消填写系统设计说明书，只须填写本说明书，直接套用“子系统模块”划分（即第3章）进行“系统模块”划分（把其中“子系统”一词替换为“系统”），并删除本说明书中“系统子系统”划分的相关内容（第2章）。
目录 1. 简介 ................................................................ 错误!未定义书签。 . 背景和目的.................................................... 错误!未定义书签。 . 范围.......................................................... 错误!未定义书签。 . 术语和缩略语.................................................. 错误!未定义书签。 2. 系统总体设计 ........................................................ 错误!未定义书签。 . 任务概述...................................................... 错误!未定义书签。 目标 .................................................... 错误!未定义书签。 需求概述 ................................................ 错误!未定义书签。 . 设计概述...................................................... 错误!未定义书签。 总体约束 ................................................ 错误!未定义书签。 系统外部接口 ............................................ 错误!未定义书签。 设计方案概述 ............................................ 错误!未定义书签。 . 系统架构设计.................................................. 错误!未定义书签。 系统的逻辑架构设计 ...................................... 错误!未定义书签。 系统的物理架构设计 ...................................... 错误!未定义书签。 . 子系统定义.................................................... 错误!未定义书签。 子系统列表 .............................................. 错误!未定义书签。 子系统间关系 ............................................ 错误!未定义书签。 3. 子系统1设计 ........................................................ 错误!未定义书签。 . 任务概述...................................................... 错误!未定义书签。 目标 .................................................... 错误!未定义书签。 需求概述 ................................................ 错误!未定义书签。 . 设计概述...................................................... 错误!未定义书签。 总体约束 ................................................ 错误!未定义书签。 子系统外部接口 .......................................... 错误!未定义书签。 设计方案概述 ............................................ 错误!未定义书签。 . 子系统架构设计................................................ 错误!未定义书签。 . 模块定义...................................................... 错误!未定义书签。
个人博客—报告(完成)
辽宁科技大学 课程设计说明书 设计题目：https://www.wendangku.net/doc/144704177.html,特定领域高级应用课程设计 个人博客系统（留言板模块）学院、系：软件学院 专业班级：软物信10班 学生姓名：杨卿林 指导教师：李林林 成绩： 2013 年07 月12 日
目录 1．绪论 (3) 1．1 开发背景 (3) 1.2课题研究的意义 (3) 1．3 相关技术知识 (4) 2．需求分析 (6) 2.1 开发背景 (6) 2.2 系统实现目标概述 (6) 2.3 系统功能需求 (7) 2.4用例图 (8) 3．总体设计 (9) 3．1 数据库设计 (9) 3.2性能需求 (9) 3.2.1多样性 (9) 3.2.2易维护 (10) 3.2.3安全性 (10) 3.2.4可扩展性 (10) 3.3功能需求 (10) 3.3.1信息服务 (11) 3.3.2查询服务 (11) 3.3.3留言服务 (11) 3.3.4前台和后台 (11) 3.4结构 (13) 3.4.1前台功能结构图 (13) 3.4.2前台文件总统架构图 (13) 3.4.3后台功能结构图 (14) 3.4.4后台文件总体架构图 (14) 4详细设计 (15) 4.1任务概述 (15) 4.2性能要求 (15) 4.3功能实现 (16)
1．绪论 1．1 开发背景 随着计算机技术的发展和普及，blog得到了极大的发展。Blog，是Weblog的简称。blog是一种新的生活方式、新的工作方式、新的学习方式和交流方式。它是继E-mail、BBS、ICQ、之后出现的第4种网络交流方式。Blog主要应用于3个方面：一是新的人际交流方式；二是以个人为中心的信息摘选和知识管理；三是以个人为中心的传播出版。blog作为个人的一种学习工具，简单易用，吸引人的兴趣。Blog在教育方面得到了很大的发展，它将互联网从过去的通讯功能，资料功能、交流功能等进一步强化，使其更加个性化、开放化、实时化、全球化，把信息共享发展到资源共享、思想共享、生命历程共享。Blog已经成为一种继课件、积件、资源库、教育主题网站等信息化教学模式之后，新的网络应用模式。它是应时代的需求而兴起的，也是应时代需求不断进步的。 1.2课题研究的意义 随着Blog人数的增加，Blog作为一种新的生活方式、新的工作方式和新的学习方式已经被越来越多的人所接受，并且在改变传统的网络和社会结构。它使交流和沟通更有明确的选择和方向性；单一的思想和群体的智慧结合变得更加有效；个人出版变成人人都可以实现的梦想。Blog正在影响和改变着我们的生活。
软件概要设计
XX 概要设计说明书
目录
错误!未找到引用源。 关键词：能够体现文档描述内容主要方面的词汇。 摘要： 缩略语清单：对本文所用缩略语进行说明，要求提供每个缩略语的英文全名和中文解释。
1简介 1.1 目的 这部分要描述文档的目的。应该指明读者。 1.2 范围 1.2.1 软件名称 对软件命名 1.2.2 软件功能 解释软件产品将完成或不完成的功能（可以直接描述也可以参考相关文档） 1.2.3 软件应用 描述软件的应用（可直接描述也可以参考其他软件文档） 1.3实现系统环境 描述本软件的硬件应用平台（主要涉及关键器件的介绍和环境组网方式） 1.3.1 器件特性描述 本器件所支持的规格、工作模式及其异同 1.3.2 器件工作原理介绍 The description of the work principle of the device we used in our solution. 1.3.3 关键寄存器介绍 The description of the registers used in the work mode our solution. 2概要设计 2.1第0层设计描述 2.1.1 软件系统上下文定义 描述系统如何与外部实体一道组成功能实体（一般用图描述）
外部实体属性描述只限于软件设计和描述相关的属性。 2.1.2 设计思路(可选) 2.1.2.1基本设计思路 说明系统采取的基本设计思路,概要描述为什么采取本方案。 2.1.2.2设计约束 1遵循标准 描述本软件所遵循的标准、规范 2硬件限制 描述本软件系统实现的硬件限制 3技术限制 描述本软件的技术限制 2.1.2.3安全性和可靠性设计方案 4遵循标准 描述本软件所遵循的标准、规范 5硬件限制 描述本软件系统实现的硬件限制 6技术限制 描述本软件的技术限制 2.1.2.4其他 描述其他有关的设计考虑 2.2第一层设计描述 2.2.1系统架构（功能分解和物理分解） 描述组成软件系统的构件（子系统、模块），描述之间的“静态”关系。一般采用系统方框图的形式。要按照子系统组成系统，模块组成子系统的方式组织描述。 系统方框图应能规定出系统的整体架构，说明组成系统的各部分是如何搭配成一个完整系统的。 系统方框图应画成二种： 一种是功能性的，说明系统有哪些功能应由哪些功能模块来实现画出这些功能模块之间、本系统与其它接口系统之间的逻辑关系；描述它们间的接口方式，遵循的协议规范等。如果是升级类产品，在原有功能方框框图上增加、删除、修改。 另一种是物理性的，说明系统由具体的哪些软件模块来实现。
概要设计说明书示例【概要设计说明书(模板)】
概要设计说明书示例【概要设计说明书(模板)】 概要设计说明书 修订记录 目录 第一章 1.1.1. 2.1. 3.1. 4.第二章 2.1.2.2.2. 3.2. 4.2. 5.2. 6.2. 7.第三章 3.1.3.2.3.3.第四章 4.1.4.2.4.3.第五章 5.1.5.2.5.3.第六章 6.1. 6.2.6.3. 补救措施......................................................... ........................................10系统维护设计......................................................... .. (10) 第一章引言 1.1.编写目的 说明编写这份概要设计说明书的目的，指出预期的读者。 1.2.背景 说明：
a.待开发软件系统的名称； b.列出此项目的任务提出者、开发者、用户以及将运行该软件的站点。 1.3.定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4.参考资料 列出有关的参考文件，如： a.本项目的经核准的计划任务书或合同，上级机关的批文； b.属于本项目的其他已发表文件； c.本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出 第二章总体设计 2.1.需求规定 说明对本系统的主要的输入输出项目、处理的功能性能要求。 2.2.运行环境 简要地说明对本系统的运行环境（包括硬件环境和支持环境）的规定。 2.3.基本设计概念和处理流程 说明本系统的基本设计概念和处理流程，尽量使用图表的形式。 2.4.结构 用一览表及框图的形式说明本系统的系统元素（各层模块、子程序、公用程序等）的划分，扼要说明每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系。 2.5.功能需求与程序的关系
个人博客系统分析概要
电子科技大学沙河校区-数学科学学院 项目实施规范 编号：JV-STD-PROJ 版本：1.0 官方网址：https://www.wendangku.net/doc/144704177.html,
官方网址：https://www.wendangku.net/doc/144704177.html,
1 概述 为了提高企业员工信息化水平，促进员工对信息化的了解和实施，XX单位决定实施员工个人博客系统。希望通过这个系统的实施达到员工间信息互通化，企业文化流通化，员工业余活动多元化等水平。因此该系统需要实现，用户文章发表，文章评论、照片共享、系统公告发布等功能。 1.1 目的 本文档是电子科技大学在XX单位的个人博客系统合同基础上编制的。本文档的编写为下阶段的设计、开发提供依据，为项目组成员对需求的详尽理解，以及在开发开发过程中的协同工作提供强有力的保证。同时本文档也作为项目评审验收的依据之一。 1.2 范围 本系统包括：用户信息、公告信息、个人相册信息、博客文章信息、投票信息及朋友信息六个模块。系统功能为本说明书与附件Demo版界面描述中功能的并集。在上述文件未明确描述的情况下，应能满足合同和相关投标书所描述的功能。 1.3 读者对象 系统分析、开发、测试、评审等所有参与的用户。 1.4 参考文档 无 1.5 术语定义 定义所使用的术语。对于易混淆的客户常用语要有明确规定定义。例如，“用户”是指客户的雇员而非软件的最终购买者等。
2 系统说明 2.1 概述 在这一部分应对影响系统的主要因素进行描述。对于系统的详细功能描述应在下一节进行。在此，应侧重需求的背景并使在下一节所做的叙述易于理解。可包括：现有系统描述、新系统解决方案描述、产品用途、产品功能、用户特点、局限性、前提和假设等。 2.2 产品介绍 2.3 产品中的用户与角色 2.4 产品范围 2.5 产品应当遵循的标准或规范
在线交易二手市场系统概要设计说明书
在线交易二手市场系统概要设计说明书概要设计说明书 信息与电气工程学院 软工1401 ** 201422******
1.引言 1.1编写目的 此概要设计说明书实现一个简易的基于校园网在线交易二手市场系统，对交易管理系统的总体设计、接口设计、界面总体设计、系统出错处理设计以及系统安全数据进行了说明，在以后的软件测试以及软件维护阶段也可参考此说明书，以便于了解在概要设计过程中所完成的各模块设计结构，或在修改时找出在本阶段设计的不足或错误。 1.2背景 A．待开发软件系统名称为: 在线交易二手市场； B．任务提出者：** 开发者：** C．使用用户能在校园网上进行交易的系统。 D. 按照《在线交易二手市场系统需求分析说明书》为基础来具体细化系统所具备的所有功能及功能的实现方法和接口。 1.3 开发环境 Visual Studio 2010 Mircosoft sql server 2008 Express
PowerDesigner 15.1 1.4定义 本系统:基于校园网的在线交易二手市场系统设计与实现 1.5参考资料 《基于校园网在线交易二手市场需求分析说明书》 《项目计划表》 《校园网在线交易二手市场系统_数据库模型》 2.总体设计 2.1设计目标 基于校园网的在线交易二手市场主要实现以下目标： ⑴为师生提供展示商品及表现学校形象的平台。 ⑵为用户提供商品信息查看、在线商品订购、商品浏览等功能。 ⑶采用动态网页技术，使页面中展示的商品信息更具时效性、先进性。 ⑷提供客户互评及客户给商品评论功能，收集用户对商品的意见及看法。 ⑸提供后台管理页面，简化了用户信息、商品信息、订单信息等系统数据的维护操作。 2.2运行环境
软件概要设计说明书
xxx项目概要设计说明书 （xxx模块） 拟制日期yyyy-mm-dd 评审人日期 批准日期 签发日期
文档修订记录
目录 1. 简介错误!未定义书签。 . 编写目的...................................................... 错误!未定义书签。 . 适用范围...................................................... 错误!未定义书签。 软件名称 .................................................. 错误!未定义书签。 软件功能 .................................................. 错误!未定义书签。 软件应用 .................................................. 错误!未定义书签。 . 定义及关键词.................................................. 错误!未定义书签。 . 参考资料...................................................... 错误!未定义书签。 2. 第0层设计描述 ................................................... 错误!未定义书签。 . 软件系统上下文定义............................................ 错误!未定义书签。 . 设计思路(可选) ................................................ 错误!未定义书签。 设计可选方案 .............................................. 错误!未定义书签。 设计约束 .................................................. 错误!未定义书签。 其他 ...................................................... 错误!未定义书签。 . 系统结构...................................................... 错误!未定义书签。 系统结构描述 .............................................. 错误!未定义书签。 XXX模块................................................... 错误!未定义书签。 3. 第一层设计描述 ................................................... 错误!未定义书签。 . 模块的系统结构................................................ 错误!未定义书签。 模块内部结构 .............................................. 错误!未定义书签。 业务流程说明 .............................................. 错误!未定义书签。 . 分解描述...................................................... 错误!未定义书签。 XXX子模块................................................. 错误!未定义书签。 数据设计 .................................................. 错误!未定义书签。 . 依赖性描述.................................................... 错误!未定义书签。
概要设计说明书---案例
＜网上书店＞ 概要设计说明书 作者：XXXXXXXXXXX 完成日期：XXXX年4月XX日签收人：XXXXXX 签收日期：XXXX年X月XX日修改情况记录：
目录 1 引言 (1) 1.1 编写目的 (1) 1.2 范围 (1) 1.3 定义 (1) 1.4 参考资料 (2) 2 总体设计 (2) 2.1 需求规定 (2) 2.2 运行环境 (3) 2.3 基本设计概念和处理流程 (3) 2.4 结构 (4) 2.5 功能需求与程序的关系 (8) 2.6 人工处理过程 (9) 2.7 尚未解决的问题 (9) 3 接口设计 (10) 3.1 用户接口 (10) 3.2 外部接口 (10) 3.3 内部接口 (10) 4 运行设计 (10) 4.1 运行模块组合 (10) 4.2 运行控制 (10) 4.3 运行时间 (11) 5 系统数据结构设计 (11) 5.1 逻辑结构设计要点 (11) 5.2 物理结构设计要点 (11) 6 系统出错处理设计 (12) 6.1 出错信息 (12) 6.2 补救措施 (12) 6.3 系统维护设计 (12) 7 阶段小结 (12)
1 引言 1.1 编写目的 服务于书店的网络化运营，管理用户购买以及其它服务、管理各类图书信息以及图书销售中的各个环节，最终用户为使用本网上书店的各类用户以及网上书店的系统管理人员和维护人员。 1.2 范围 说明： a．待开发的软件系统的名称：XXXX网上书店 b．任务提出者：刘俊铖、马俊 开发者：马俊、张倩、刘俊铖、张瑞鑫、唐志军、冯庆丰 用户：欲使自己书店网络化运营的各类书店。 使用本软件的单位：待定 1.3 定义 UML：Unified Modeling Language , 统一建模语言。 类图（class diagram）：表述系统中各个对象的类型及其间存在的各种静态关系。静态关系包括关联和子类型两种。 交互图（interactive diagram）：是表述各组对象如何依某种行为进行协作的模型。包括顺序图和协作图。 可修改性：容许对系统进行修改而不增加原系统的复杂性。 有效性：软件系统能有效地利用计算机的时间资源与空间资源的能力。 可靠性：能够防止因概念、设计和结构等方面的不完善造成的软件系统 失效，具有挽回因操作不当造成软件系统失效的能力。
《博客系统》概要说明
《个人博客系统》概要说明 版本V1.0 1引言 1.1编写目的 本概要说明为系统的详细设计、实现、测试以及验收提供参照，也为评价系统功能和性能提供标准。本概要设计适用于用户、项目管理人员、系统分析人员、程序设计人员以及系统测试人员阅读和参考。 1.2背景说明 博客的精神是：自由表达，开放宽容，个性张扬，专业精神，交流交友。 在没有自己的博客之前，人们会经常进出于论坛发表贴子或者通过即时通信软件聊天，来表达自已的想法，可是这些都是零散的和杂乱的。博客的出现，让人们可以不断的把自己以前的和每天激发的一些想法或者感受整理放在自己的博客上，每次在写文章的时候，可能又会产生新的想法。虽然一些想法一些思考只是皮毛，没有什么深度，但是当下笔去写的时候每次都会对某个小小的问题有了更多的一点点思考，再写博客的时候就感觉到了一种满足感，一种想法得以释放思考得以延伸的满足感。生活中每天的一个小小的事情都会引起人们的思考，甚至是和朋友的聊天中一个小小的火花迸发。督促自己努力、把一时的想法变成观点，争取在生命中的每天里留下点什么，这也是人们写博客的目的之一。这样就能督促自己每一天不要浑浑噩噩，时光
流逝无痕无声无息，写博客也是在自己的每一天上留下了一道浅浅的思考和划痕。不仅如此，通过写博客、记录自己的想法可以帮助实现如下这些目的： a）记录生活，在自己的每一天上留下思考的划痕。 b）整理思路，固化知识，获得更多更好的想法。 c）分享，将自己的想法、经验与人分享。 d）交流、提高，通过交流产生更多的思维火花，相互提高。 e）交友，互相鼓励，一路同行。 如果说博客网站是一个舞台，那么所有的博主都是其中的舞者，把自己有价值的真实的一面展示在网络世界中，相互交流沟通；如果博客仅仅为了写日志，那么博客是一面镜子，镜子中展现的是真实的自己；如果博客是一个自由媒体，可以把自身感觉有价值的信息通过博客这个工具发布，与网友共享。 2任务概述 2.1目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。
概要设计的写法
概要设计的写法 做软件到一定层次了，就要考虑到设计了，设计了很久，就是不系统，系统的设计需要一个记录，记录就用文档，那么对项目所有包括技术上的设计都记录下来，我们就可以理解为软件的概要设计了。在需求明确、准备开始编码之前，要做概要设计，而详细设计可能大部分公司没有做，有做的也大部分是和编码同步进行，或者在编码之后。因此，对大部分的公司来说，概要设计文档是唯一的设计文档，对后面的开发、测试、实施、维护工作起到关键性的影响。 概要设计写什么？概要设计怎么做？如何判断设计的模块是完 整的？为什么说设计阶段过于重视业务流程是个误区？以需 求分析文档还是以概要设计文档来评估开发工作量、指导开发计划 准确？结构化好还是面向对象好？以上问题的答案请在文章 中找。 二、概要设计的目的? 将软件系统需求转换为未来系统的设计；逐步开发强壮的系统构 架；使设计适合于实施环境，为提高性能而进行设计；结构 应该被分解为模块和库。 三、概要设计的任务? 制定规范：代码体系、接口规约、命名规则。这是项目小组今后共 同作战的基础，有了开发规范和程序模块之间和项目成员彼此之间 的接口规则、方式方法，大家就有了共同的工作语言、共同的工作 平台，使整个软件开发工作可以协调有序地进行。总体结构设 计：功能（加工）－>模块：每个功能用那些模块实现，保证每 个功能都有相应的模块来实现；模块层次结构：某个角度的软件 框架视图；模块间的调用关系：模块间的接口的总体描述；模 块间的接口：传递的信息及其结构；处理方式设计：满足功能 和性能的算法用户界面设计；数据结构设计：详细的数 据结构：表、索引、文件；算法相关逻辑数据结构及其操作；上 述操作的程序模块说明（在前台？在后台？用视图？用过程？······）接口控制表的数据结构和使用规则其他性能设计。 四、概要设计写什么?