概要设计

概要设计说明书

Version 1.0

文档名称：邮件管理系统系统设计（概要设计）说明书

修订历史记录

日期	版本号	修改说明	修改人	核准人
2008/4	1.0	首次撰写	童方圆

目录

1 引言 4

1.1 目的与范围 4

1.2 预期的读者 4

1.3 方法学 4

1.4 定义、缩写词 4

1.5 参考资料 4

2 环境说明 4

3 设计目标与权衡 4

4 系统设计 4

4.1 子系统分解 4

4.2 硬件/软件映射 5

4.3 软件控制流设计 5

4.4 异常处理设计 5

4.5 访问控制与安全性 5

4.6 数据设计 5

5 子系统服务 5

6 变化列表 5

7 附录 5

概要设计说明书

1 引言

1.1 目的与范围

本文档为邮件管理系统的系统设计文档。

本文档包括开发系统的子系统分解图（用UML包描述）；子系统的硬件/软件映射；数据管理；访问控制；设计全局控制流；描述边界对象。

对子系统分解做了比较详细的说明，可以帮助进一步完成后面的详细设计部分；对于部署图部分也做了说明，帮助更好的理解系统。

[本文档的作用与目标的描述，本文档包含的内容与范围。]

1.2 预期的读者

本文档预期读者为：对象设计人员，开发人员，项目经理，测试人员。

[列举本文档所针对的不同读者，例如对象设计人员、开发人员、项目经理、测试人员等。描述文档的组织结构，提出最适合每一类读者阅读的阅读建议。可以用超链接技术把各角色所关心的内容列出来，进行方便地跳转。]

1.3 方法学

1. 为了有效地进行系统设计，在此采用“三层体系结构风格”来组织子系统

三层体系结构风格：系统分为三层（接口层，应用逻辑层，存储层）。接口层包括所有与用户打交道的边界对象；应用逻辑层包括所有的控制和实体对象；存储层实现对持续性对象的存储，检索和存储。

2. 设计思想：将系统模型基本划分为上述三层进行建模。

3. 设计过程：分析可知邮件管理系统大致可以定位为三层体系结构。

接口层：系统界面提供了用户与系统的接口；

应用逻辑层：界面上的按钮提供了连接操作，每一个按钮基本上都对应一个类，提供一系列相关的操作；

存储层：为了减少数据库子系统和其他系统的高耦合状况，增加了一个新的子系统：存储子系统。

[说明设计所采用的方法学，对其思想、设计过程、辅助工具做简短的描述。]

1.4 定义、缩写词

本系统：邮件管理系统

普通用户：本校（中国地质大学（武汉））注册教师，学生

个人信息管理：普通用户级相关信息管理

管理员：邮政中心的服务人员，也即进行邮件相关操作的工作人员。也称邮件管理员

系统管理员：邮政中心的负责人

用户：普通用户和管理员的统称。

[说明本文件使用到的定义、缩写词等。]

1.5 参考资料

面向对象软件工程（使用UML，模式，JAVA），清华大学出版社

数据库系统概论（第四版）高等教育出版社

[对本文档中涉及到的参考资料进行列表描述。对列表中的每一种资料，都要指明版本与出处。此处应该包括SRS、合同等作为参考。]

2 环境说明

数据库采用access,客户提供，在模拟运行时候，采用下载版。

[对硬件, 软件, 第三方软件说明, 操作系统,网络, 开发工具, 文档工具等进行描述，清晰定义出系统所处的环境。]

3 设计目标与权衡

设计准则分为5组：性能准则，可靠性准则，成本准则；维护准则；最终用户准则。

根据需求规格说明书的非功能性需求对以下设计目标间的冲突进行权衡/

设计目标之间的权衡：

1. 时间和空间：系统将优先考虑空间（本系统对速度要求不是太高，或者相对于吞吐量而言，响应时间地位次之）；

2. 交付时间和功能：优先考虑功能（本系统更强调功能的稳定性，正确性，交付时间可以稍微予以缓和）；

3. 交付时间和质量：优先考虑质量（本系统更强调软件的质量和可靠性，如果难以与交付时间折中，交付时间可适当缓和）；

4. 功能性和可用性：优先考虑功能性（本系统更强调软件功能能够可靠实现，当与可用性发生冲突时，可适当向功能性偏移，但要保证功能可以使用）；

5. 成本和可重用：优先考虑可重用性（随着通信的不断发展，客户还准备在以后进行功能的进一步扩充和完善，更要求可重用性）；

[在这一节中，要描述系统地设计目标是什么？对一些互相冲突的目标要进行权衡。可以考虑如下的问题：设计中优先级最高的目标是什么？在多个目标间权衡的依据是什么？本节写作时可参阅 《设计指南》。

设计目标的确定主要来自于非功能性需求于项目的实际情况。 ]

4 系统设计

4.1 子系统分解

1. 相关基本概念：

A． 三层设计模式（参见方法学1.3）；

B． C/S模式（客户服务器模式）：服务器负责为客户子系统提供服务，客户负责与用户的交互。

C． MVC体系结构风格（模型/试图/控制器体系结构风格），模型子系统维护域内知识；视图子系统为用户提供显示；控制器管理和用户的交互顺序。模型子系统的开发部依赖于任何视图或控制器子系统。模型子系统状态的改变是视图子系统通过通过预订/通知协议来传播的。

D． B/S 模式（浏览器/服务器模式）：服务器启动后，用户不用相应的客户端软件，只用IE

浏览器就可一访问。不用在客户端安装任何应用程序，只要操作系统带浏览器就可以实现各种应用操作。（保持了图形化的用户界面，又大大减少了应用维护量。而今的服务器性能的提高，可以承担后台的支持，而且B/S结构下可以通过不断增加服务器的方式非常方便地分散服务器的负载，不会象主机终端方式下只能依赖一台服务器的能力）。

E． 分层：层是提供一组相关服务的子系统，它多半是通过使用另一层服务来实现本层的功能；每一层依赖于下一层，对上一层一无所知。（在本系统中采用开放体系结构）；

F． 划分（分区）：将系统分解为对等的子系统，每个子系统负责一类不同的服务。

G． 耦合度：子系统之间的依赖程度；

H . 聚合度：子系统内部的依赖程度。

2. 对整个系统，采用三层体系结构风格进行第一步的分解（参见1.3方法学）；

3. 对于系统从界面到控制的部分采用MVC的体系结构思想：

A．通过界面上按钮触发操作控制；

B．操作控制经过信息的初步处理，决定调用内部哪一个系统（即个人信息管理，邮件管理和管理员）；

C．具体的管理系统根据操作控制给定的信息进行进一步的处理操作；

D．具体的管理系统与存储打交道，以提取有关信息；具体管理系统综合存储给出的信息；

E．具体管理系统将结果反映到具体的界面上（或视图上）。

4. 子系统分解情况为（UML类图）：

子系统分解说明和分析：

A. 系统界面显示：提供用户和系统进行交互的接口，关于系统界面的样式在需求规格说明书中的系统界面图中进行大致的描绘。可以通过界面上的按钮向系统发送消息，对于错误的输入信息(在需求规格说明书中已经提到，主要是输入的格式不匹配)。对于检测没有格式错误的信息，发给操作控制子系统进行进一步的处理。同时该系统负责出路两个比较简单的功能：退出系统，重新登录。

B. 操作控制子系统：由于在系统界面上提供的功能比较多，而且有些还比较复杂，于是就需要对于一些比较复杂比较重要的请求，分开处理。在这里我的初步想法是将一些比较简单的功能交给系统界面处理（上面已经进行的介绍），而将一些比较复杂的功能在这一步进行判别并交给具体的子系统进行全面处理。这部分其实是根据用例图中的邮件管理进行了一些补充（主要是加入了个人信息管理和管理员信息管理），因为主要是考虑到这两部分比较复杂，不应放在前一系统（系统界面显示）中，并且这两部分都有访问数据库的操作，放到后面更觉协调。

C. 个人信息管理：负责处理有关个人信息部分的相关服务。操作控制对象对用户请求进行判别发现是有关个人信息的请求，于是向个人信息管理子系统发信息，要求对请求予以处理。在这里的个人（指的是在需求规格说明书中所说的普通用户）。它提供的具体功能有对应用例图中的“修改个人部分信息”，对应界面图上的“个人信息”其实这部分的功能并不是很少很简单，在需求规格说明书中对该用例进行描述时，提供了一个图，也即个人资料界面（大致的描述），在这里将更具体描述这一部分：1.对姓名和账号这两个属性，普通用户无权修改；2.用户可以对电子邮箱和密码进行修改，可以按确认将修改提交，也可以按取消对操作进行取消；3，提供新邮件和历史邮件两项功能，可以点击对新邮件和历史邮件进行查询，结果将返回给用户查询结果，返回的结果格式同查询结果格式，可以参照图查询结果（需要补充的是，这时没有了下面的三项服务，因为普通用户对它们的操作势必让数据库混乱不堪）；4，该子系统实现人员需要按照上述要求完全实现所有要求的功能。

D. 邮件信息管理：负责对有关邮件的各种要求提供服务。主要是录入，领取，查询，过期邮件这四项操作。在需求规格说明书的用例中对上述功能已经做了比较清晰的描述，在这里就不再废话了。可以参阅需求规格说明书的对应内容。需求规格说明书当然在这里需要就几个比较问题进行一下重申：1，录入操作的输入格式不正确，需要提供报错；2.领取操作只是对邮件状态进行更改，也即改为已领取状态，点击领取按钮系统自动执行这一步的操作；3.在查询结果图中提供了三项操作，对于其中的删除操作，需要按照HR_6删除邮件信息和文档设置不显示；4.该部分子系统需要严格按照要求完成。

E．管理员信息管理：负责提供管理员信息的相关管理。其实这部分内容在前面的分心中都采取了回避的态度，理由是它不是很重要，至少在前面看来。在这里，将这部分内容添加进来，主要是因为现在已经是系统设计了，需要做做补充了。系统管理员需要对管理员信息管理，所以很有必要把这一部分内容加进来。其实这一部分主要是一个监督机制，在需求规格说明书其实也提到过，在邮件管理员基本信息项（在需求规格说明书的靠后部分）添加了登录时间和退出时间属性，这两个属性值由系统根据管理员的作息自动进行记录，这样系统管理员不需要天天去监督，换言之，我们让系统提供“远程控制”。这部分不需要什么直接的输入，这部分需要实现的功能有：1.系统能自动记录管理员登陆和退出时间，并与管理员工号进行绑定；2.如果管理员对邮件信息由删除记录（关于删除部分，邮件管理子系统已经提及，可以参阅相关部分），系统需要通知系统管理员（发提示信息）；3，本部分非本次课程核心（由可能不实现）

F．存储：为了降低数据库与个人信息管理，邮件管理，管理员信息管理之间的耦合，添加该子系统，通过它实现对后台数据库的访问。在存储部分需要实现：1，根据查询要求，调用自身查询函数，在数据库中进行查询，并返回查询结果，若查不到，返回出错信息（0）；2，对于修改请求，先执行查询操作，若查不到，返回出错提示（0），否则，返回查询结果；3，对于删除请求，先执行查询操作，若查不到，返回出错信息（0），查到就按照设置不显示进行相关操作。

G．数据库：存储信息。数据库在开始就将全部基本信息进行保存，包括：所有普通用户的账号和姓名，也即所有在校注册学生的班号和姓名，所有在校注册教师的教师号和姓名。数据库中存储有：普通用户基本信息项，邮件管理员基本信息项，以及邮件基本信息项（对于上述三项的具体信息都在需求规格说明书中进行了比较详细的说明）。此部分为客户要求，需要严格按要求执行。

H．进一步说明：1.在类图一中主要提供了登陆过程的一些类，所以对于登陆这一部分在这里没有重复，在具体安排实现的时候，将这部分的实现交由系统界面显示子系统完成；

2.对于个人信息子系统和邮件管理子系统的实现可以参阅类图二，在类图二中提供了一些与这两个子系统有关的类，可以参考。

3.对于其他子系统，根据上面的说明实现。对于管理员信息管理可以暂时不实现。

I． 在下一步的设计中，需要按照上面的要求作出每一个子系统的具体类图，并通过层面设计模式提供一个子系统接口,在子系统接口中提供上述功能。并根据要求对每一个类进行设计。

5. 将子系统分配到构件（UML部署图）：

6.构件与子系统之间的关系：

用户构件：在子系统分解的表示图中，没有画出这一部分，而仅仅用用户界面显示来隐含表示（进一步说明）。内部的过程是这样的：管理员与服务器之间是通过C/S体系结构风格进行交互，普通用户与服务器之间通过B/S模式进行交互。在这里的用户构件包含了客户机或者是浏览器，由于不好描述，在上图中没有表示出来，而直接表示成最终的效果，也即用户成功登陆到系统，准备执行相关操作。

普通用户信息服务：提供对普通用户信息的相关服务。对应子系统分解图中的个人信息管理（当然是通过操作控制进行过渡的）

管理员信息服务：提供对管理员信息的相关服务。对应子系统分解图中的管理员信息管理（基于操作控制子系统）

邮件信息服务：提供对邮件的相关服务。对应子系统分解图中的邮件信息管理（基于操作控制子系统）

存储：对应子系统分解图中的存储和数据库。

7.实际可能的改进：

分开设置普通用户信息服务，管理员信息服务，邮件信息服务使得构件数量比较多，可以进行合并，也即将这三个构件合为一个系统服务构件。分开描述主要是为了更清晰地进行描述。

[1、本节是概要设计中非常重要的一个部分。可以先介绍与本设计相关的一些子系统的基本概念，比如Client/Server，Peer/peer等基本架构的原理，分区与分层的基本概念等。

2、针对本系统，提出本系统的子系统的划分情况，每个子系统的主要职责或服务，采用合适的表达方式清晰地描述分解结果。（如果利用面向对象的设计，则可以使用包表示子系统，利用由包组成的类图来描述子系统的划分以及它们之间的关系。

3、设计组成系统的构件图，说明系统的开发中的构件（比如动态库、COM组件、可执行文件等），以及它们之间的关系。说明构件与子系统之间的关系。]

4.2 硬件/软件映射

1. 管理员与系统的交互（C/S体系结构风格）

说明：客户机部分包含用户构件，服务器部分包括：普通用户信息服务，邮件管理服务，管理员信息服务，以及存储，对于内部一些信息4.1子系统分解。

2. 普通用户与系统的交互（B/S体系结构风格）

说明：考虑到普通用户是通过浏览器登录系统的，为了更好地实现通信，在这里添加了通信服务构件（这在前面的子系统分解图中没有提到），原因是在本系统的具体实现中，我们仅仅将工作的中心放到实现C/S体系结构风格上，也即中的请按实现客户机与服务器的交互，所以这部分不是重点，可以作为以后继续完善设计的参考。

用户机通过通信连接，访问服务器，系统服务（参见4.1——7实际可能的改进）提供系统提供的各项服务。

[1、表示出系统中的硬件的分布与关系，比如PC与服务器之间的关系等。

2、每个硬件上运行的构件的描述。表达出系统的部署图，描述各构件所运行的位置。]

4.3 软件控制流设计

本系统的全局控制流其实是很清晰的，我们采用面向对象的设计方法，用事件驱动进行控制。在前面的分析中已经比较明显：几乎全部的的服务在系统界面上都展现给了用户，然后根据用户的要求执行相关的操作处理。

用户通过输入信息和点击相关按钮向系统发送消息，系统根据消息做出相关动作。

为了更加清晰的描述，在这里将其中一个比较复杂的过程进行一下描述（需求规格说明书中用顺序图描述过的过程），用户领取邮件顺序图

在用例的场景中对事件的执行流程也做了比较详细的描述，可以参考。

[控制流是系统中动作的先后顺序，要设计系统所采用的控制流方式，比如过程驱动控制、事件驱动控制、多线程并发控制。并且要考虑在与外部系统交互的时候所采用的控制流方式。]

4.4 异常处理设计

对于异常处理前面有些地方提到，在这里做汇总和补充：

1. 用户需要通过帐号和密码登录系统，如果出现账号不存在或者密码与账号不匹配，系统弹出出错提示（需求规格说明书用例HR-1），这部分在系统界面显示子系统中要实现；该部分设置防止非法用户的入侵。

2. 对于用户对信息输入格式错误时，需要提示，以便用户更改输入；可以参见需求规格说明书的相关用例；

3. 为了正确地记录管理员的工作情况，系统每隔五分钟对管理员的退出系统时间进行一次更新（在需求规格说明书附录部分的管理员基本信息项中提到）；

4. 当管理员录入邮件时，系统更改数据库信息后，返回给管理员成功录入；如果出现断电情况，或者管理员没有看到系统返回的成功录入提醒，就需要进行二次录入。如果是系统本身问题，不能完成此次录入，也需要返回给用户为成功录入提示信息；

5. 对于邮件删除，参见设置不显示.doc

6. 如果由于内部软件设计出错而导致不能执行用户的请求，需要返回给用户系统忙碌，或者系统错误信息，系统停止对用户请求的服务。（系统要具备一定的容错机制）

[对如何处理主要故障与异常情况，比如由软件错误或者断电引起的数据崩溃等进行设计。]

4.5 访问控制与安全性

对于访问权限的统计在前面已经进行了一些分析，在这里进行了一些改动，参见文档用户权限统计表格.doc

[描述从访问矩阵的角度建立的系统用户模型。描述安全性问题，比如选定一个鉴别机制、加密的使用、密钥的管理等。]

4.6 数据设计

采用关系数据库进行数据的存储。

对于这部分的详细说明，提供了比较详细的说明，参见文档数据设计

[对系统中需要管理的各种数据，用什么方式进行管理进行设计。

对放到数据库中管理的数据，要描述出表、表之间的关系、视图、触发器、储存过程接口等设计。可以利用表格等方式在这里直观地表示，也可以利用CASE工具进行设计，将设计结果模型作为设计说明书的附件。]

5 子系统服务

在对子系统进行分解中对子系统提供的服务以及相关情况都做了比较详细的说明，在这里就不在重复了，可以参见4.1子系统分解

[描述每个子系统提供的服务，这里的服务一般只用函数名称及简单说明就可以了，各函数具体的规格说明将在对象设计中进行说明。可以利用表格形式进行描述。]

6 附录

[把其他与设计相关的文档放在这里，可以直接写在文档中，也可以放到其他文档中，在这里进行索引。比如利用其他工具所做的各种模型文件等。]