软件概要设计说明书类图顺序图

合集下载

软件项目概要设计说明书模板

软件项目概要设计说明书模板

软件项目概要设计说明书模板XXXXXX公司二零二三年十二月第 1页共14页修订记录第 2页共14页目录目录 (3)1文档介绍 (5)1.1文档目的 (5)1.2文档范围 (5)1.3读者对象 (5)1.4参考文献 (5)1.5术语与缩写解释 (5)2系统概述 (6)3设计约束 (6)4系统总体功能结构 (7)4.1系统管理子模块 (7)4.1.1系统管理子模块功能结构 (7)4.1.2系统管理子模块功能描述 (7)4.2XX子模块 (8)4.2.1XX子模块功能结构 (8)4.2.2XX子模块功能描述 (8)4.3党委个人XXXX子模块 (9)4.3.1党委个人XXXX子模块功能结构 (9)4.3.2个人XXXX模块功能描述 (9)4.4XX子模块 (9)4.4.1XX模块功能结构 (9)4.4.2子模块功能描述 (9)4.5消息管理子模块 (10)4.5.1消息管理子模块功能结构 (10)4.5.2消息管理子模块功能描述 (10)4.6汇总统计子模块 (10)第 3页共14页4.6.1汇总统计子模块功能结构 (10)4.6.2汇总统计子模块功能描述 (10)4.7预警提醒子模块 (11)4.7.1预警提醒子模块功能结构 (11)4.7.2预警提醒子模块功能描述 (11)4.8和XXX数据同步子模块 (11)4.8.1和XXX数据同步模块功能结构 (11)4.8.2和XXX数据同步子模块功能描述 (11)5开发环境的配置 (12)6运行环境的配置 (13)7测试环境的配置 (14)第 4页共14页1文档介绍1.1文档目的本文档作为详细设计阶段所提交材料的重要组成部分,内含设计策略,软件联系逻辑,系统总体结构以及子系统的结构和功能,为产品后续开发提供重要参考。

1.2文档范围针对做个性概要分析设计。

适用于整个XXXX系统的开发过程。

1.3读者对象本说明书适用于项目设计人员、开发人员、测试人员、文档编写人员、工程实施人员。

UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明书画法和功能

UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明书画法和功能

UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML(也就是Unified Modeling Language ™),这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标,即:∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题,测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题,我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂,设计师和施工人员之间的交流就越重要.蓝图就成标准文档为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂,参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师,设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师,设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的,它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事(属性attributes)和他们可以做的事(行为或操作behaviors or operations).对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性(数据)和行为(方法或函数).对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间,并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association(或简称通讯communication)标准文档角色是人状的图标,用例是一个椭圆,通讯是连接角色和用例的线.一个用例图是角色,用例,和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征(需求).当系统已经分析好并且设计成型时,新的用例产生新的需求标准文档∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的-它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式:Cash,Check,或者Credit.订单包括OrderDetails(line item),每个这种类都连着Item.标准文档UML类的符号是一个被划分成三块的方框:类名,属性,和操作.抽象类的名字,像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association-表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中,关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图,可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型.dependencies关系.如果另一个的包B改变可能会导致一个包A改变,则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时(特别是递归关系时)很有用.这个类图示一个大学的Department可以包括其他很多的Departments.标准文档这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚,类或实例名可以在对象图中被省略.标准文档每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴,时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时,角色用一条虚线表示,当对象的过程处于激活状态时,生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.标准文档协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息,但他们不关心什么时候消息被传递,只关心对象的角色.在序列图中,对象的角色放在上面而消息则是连接线.标准文档对象角色矩形上标有类或对象名(或者都有).类名前面有个冒号(:).协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息(也就是同一个调用中的消息)有同样的数字前缀,再根据他们出现的顺序增加一个后缀1,2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.标准文档我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号,再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态:Getting SSN, Getting PIN, Validating, 以及 Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.标准文档状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN,另一个则在上Getting PIN.初始状态(黑色圆圈)是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用(/动作)表示.当进入Validating状态时,对象并不等外部事件触发转移.取而代之,它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上,而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说,我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和 Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。

软件概要设计说明书类图顺序图

软件概要设计说明书类图顺序图

软件概要设计说明书类图顺序图TPMK standardization office【 TPMK5AB- TPMK08- TPMK2C- TPMK18】软件概要设计说明书 (2)1.概述 (2)1.1 软件设计目标 (2)1.2 参考资料 (2)2 术语表 (2)3 用例 (2)4 设计概述 (3)4.1简述 (3)4.2系统结构设计 (3)4.1.1 物理模型: (3)4.1.2 软件功能结构图: (4)4.3系统层次划分 (5)4.4设计用况的类图、顺序图 (6)4.4.1市民上报问题 (6)4.4.2上级下达命令 (10)4.4.3街乡二级平台上报问题 (13)4.4.4(监督员)登记问题(接线员上报问题) (15)4.4.5值班长核查问题 (18)4.4 约束和假定 (21)5 非功能性需求 (21)软件概要设计说明书1.概述本说明书主要描述朝阳区城市网络化管理信息系统的子系统的各个模块的设计;包括登录模块,登记问题模块,市民上报问题模块,上级下达命令模块,街乡二级平台上报问题模块,核查问题模块,以及立案模块。

将针对上述模块的功能进行面向对象的分析并完成相应用例的顺序图,相应对象的状态图的设计以及系统总体构架和配置。

对系统的性能,可用性等非功能需求也有相应描述,供详细设计人员和项目小组以及用户参考。

1.1软件设计目标我国数字城市技术应用现已逐渐应用到社会的各个领域中。

为了节约大量的人力、物力、财力。

网格管理新模式的提出将解决人们一串串“投诉没门路、解决无期限”的烦恼。

本系统主要实现朝阳区城市网络化管理信息系统中的信息提交子系统功能。

具体针对各个模块进行概要设计,模块化结构更清晰。

1.2参考资料中华人民共和国国家标准:《城市市政监管信息系统技术规范》;《城市市政监管信息化部件和事件分类与编码》;《城市市政监管信息化单元网格划分与编码》;《城市市政监管信息化地理编码》;《软件需求规格说明书》2术语表UML 统一建模语言3用例系统顶级用例图:4设计概述4.1简述本说明书采用的设计方法为面向对象设计法;系统的体系结构为B/S结构;相应技术为 UML_Rational Rose.4.2系统结构设计4.1.1物理模型:配置图:1.节点说明Web服务器:Happy 2005 2.40GHz CPU,512MB内存,20GB*4硬盘;操作系统:Windows XP;数据库服务器: MS SQL Server 2000;浏览器:IE5.0。

UML建模工具软件StarUML从入门到精通——软件系统详细设计中的UML顺序图及其组成部件

UML建模工具软件StarUML从入门到精通——软件系统详细设计中的UML顺序图及其组成部件

(3)软件系统的开发实现人员 软件系统的开发实现人员看到需要开发的对象和它们的操作 ,因为对象间的通信通过在对象的生命线之间画出消息来表示。
(4)软件系统的测试相关人员 软件系统的测试人员能够通过顺序图看到过程的细节,并根 据这个过程开发出测试用例。
7、顺序图的组成元素及示例
(1)顺序图的组成元素 顺序图中的生命线、激活点是序列图所特有的图形元素,用 于表现对象之间的交互与消息的时间顺序。
(4)带有条件的消 息——在消息上面给 出条件的表达式
11、顺序图中的激活期
(1)激活期的含义 激活期表示对象执行一个动作的期间,即对象激活的时间段 -----当收到消息时,接收对象立即开始执行活动,即对象被激 活了。 (2)在UML中的表示法 通过在对象生命线上显示一个细长矩形框来表示激活。 (3)应用要点 1)当一个对象在激活期时,该对象处于激活状态,能够响应 或发送消息,执行动作、活动。 2)当一个对象不在激活期时,该对象处于休眠状态,什么事 都不做,但它仍然存在,等待新的消息来激活它。
软件系统详细设计中的 UML顺序图及其组成部件
1、什么是顺序图
(1)顺序图作为交互图中的一种,它显示参与交互作用的参与 者或对象,以及它们生成的按时间排序的事件。 (2)顺序图能够显示特定用例实例产生的事件并且侧重描述消 息在对象之间如何传送等方面的信息。 (3)顺序图由于是按时间顺序对控制流进行建模,因此主要用 于对用例中的控制流的建模。 (4)顺序图显示出随着时间 的变化对象之间是如何通信。
(3)顺序图反映了参与者与系统之间的交互,以销售为例,参 与者为收银员,场景中对象有登录界面以验证权限、库存查询接 口,用以判断库存中是否有数据、销售处理接口,其结果是从库 存中减掉对应数量的图书。

软件项目概要设计说明书(模板)Word版

软件项目概要设计说明书(模板)Word版

××_软件项目概要设计说明书版本:编制:审核:批准:颁布日期:2017年4月18日受控状态:■受控□非受控分发范围:项目组、财务部、质量管理部修订记录传播优秀Word版文档,希望对您有帮助,可双击去除!目录1 引言 (1)1.1 概述 (1)1.2 目的 (1)1.3 范围 (1)1.4 缩略语 (1)1.5 术语 (2)2 参考资料 (2)3 交付需求列表 (2)4 系统物理架构 (2)4.1 系统运行的硬件环境 (2)4.2 系统运行的软件环境 (3)4.3 系统运行的网络环境 (3)4.4 系统部署图 (3)4.5 安装部署说明 (4)5 系统逻辑架构 (5)5.1 子系统一 (5)1.1.1子模块一 (5)1.1.2子模块二 (5)5.2 子系统二 (5)6 实现视图 (5)7 进程视图 (6)8 数据库设计 (6)9 设计约束 (6)10 内部接口定义 (6)11 外部接口 (6)12 开发环境说明 (7)13 技术难点 (7)14 附录 (8)14.1 模型文件 (8)14.2 XXXX (8)××_软件项目概要设计说明书1引言1.1概述{应包括:a. 项目的委托单位、开发单位和主管部门;b. 该软件系统与其他系统的关系。

}本项目交办方为,承办方为。

}1.2目的{阐明编写概要设计说明书的目的,指明读者对象。

}本文档是在用户和开发方对系统进行需求开发,形成软件需求规格说明书后,设计人员分析各个详细需求后,对软件的概要设计。

本文档作为软件概要设计和软件详细设计的重要依据。

软件概要设计人员和软件详细设计人员依此作为工作依据。

1.3读者对象本系统设计说明书的使用读者为:业务经理、软件设计、UI设计人员、测试人员。

1.4范围概要设计要考虑对架构有影响的需求,将系统划分为{子系统一,子系统二},从物理架构,逻辑架构,实现视图,进程视图等四个方面对架构进行描述,定义子系统之间的接口,明确系统依赖的外部接口,说明系统开发准则,选取开发环境,对技术难点进行分析说明。

软件概要设计(总体设计)ppt课件

软件概要设计(总体设计)ppt课件

u,w
c,p r
Q
P
R
(2) 事务分析设计方法
任何情况下都可使用变换分析 方法设计软件结构,但如数据 流具有明显的事务特点时 (有 一个明显的事务中心),以采用 事务分析方法为宜。
事务分析设计方法步骤:
(1)在DFD上确定事务中心、接收部 分和发送部分。
(2)画出SC框架,把DFD上的三部分 分别映射为事务控制模块、接收 模块和动作发送模块。
模块过大:可理解程度下降 模块过小:开销大于有效操作
系统接口复杂
(6)降低模块接口的复杂性
接口传递信息应简单且和模块功能 一致。
(7) 模块功能可预测
模块看成黑盒子,相同输入产生 相同输出,其功能为可预测的。 模块带有内部状态其功能可能是 不可预测的。难理解、难测试、 难维护。
防止模块功能过分局限
D
G
N
事务流设计举例 (另一种画法)
XX系统
A
A
E、F、G
E、F、G
输入 A 变换控制
输出 E、F、G
B
C E
F
L
M
G E、F、 GH
H
D
N O 输出H
有效图书 管理要求 入库单
2.2
新书入库
借书单 2.3

2.1
借书

要求类
当前 型处理
日期
注销单
借 书
2.5
注销图书
文 件

2.4
一层数据流图 (a) 借书 罚款单
4.4.1结构图(SC Structure Chart)
SD方法在概要设计中的主要表达工具
约定:
不加区分的数据 数据信息
编辑学生记录

UML基本图示

UML基本图示

UP是软件开发过程,描述了构造,部署以及维护软件的方式。

统一过程是一种流行的构造面向对象系统的迭代软件开发过程。

Rational(RUP)统一过程是对统一过程的详细精化,并且已经被广泛采纳。

UP以构架为中心,用例驱动,迭代和增量式开发。

迭代和增量式开发分为,初始、细化、构造、交付四个过程,在初始阶段并不需要去分析全部的需求,在了解了整个业务之后找到最核心的需求,将最核心的需求分析并实现,展示给客户看,然后再客户给出新的需求后在分析需求,并将需求在初始系统的基础上扩展。

XP极限编程,是指在开发过程中不断的沟通,与客户沟通产生反馈信息,项目组内部沟通产生反馈信息,不断的修正系统,让系统朝着正确的方向发展,所以在系统交付之前,系统是变化的,不稳定的。

XP中的测试驱动开发(tdd),是指在编程之前写测试单元,即编写系统不能通过的情况,直到系统能完全通过测试单元,则系统完成;重构,在实现系统的时候修改代码;持续集成,在开始的时候存在一个核心的可用系统,然后在其上不断扩展,不断集成,每天都要存在一个可运行的系统。

UML包括:事务,关系,图,扩展机制事务:结构:类,接口,构件,节点等行为:交互(消息),状态等分组:包,子系统等注释:注释关系:依赖,关联(聚合,组合),泛化,实现图:用例图,交互图(顺序图,协作图),类图,活动图,状态图等扩展机制:Stereotype(版型),TaggedValue(标签值),ConstraintRational Rose是一种建模工具用例视图:需求分析阶段的利器逻辑视图:设计阶段,用例的实现组件视图:构件表示封装了其内容的系统模块,构件是相对独立的模块部署视图:表示软件元素在物理架构上的部署,以及物理元素之间的通信UML基本图示类图顶端“ClassName”表示类名中间部分为该类的属性,其中分别表示为可访问性,属性名,以及属性的数据类型。

第三部分为该类的方法,包括方法的可访问性,方法名,方法的参数以及方法的返回值。

软件工程顺序图

软件工程顺序图
消息用来阐明顺序图中不同活动 对象之间旳通信。它能够在一种对 象需要取消不同对象旳进程时或者 需要向另一种对象提供服务时,使 用消息。
消息从活动对象生命线到接受对 象生命线旳箭头表达。箭头以时间 顺序在图中从上到下排列。箭头上 面标识要发送旳消息,如下图所示。
把参加者表达为活动对象
旳建模能够阐明参加者怎样 与系统交互,以及系统怎样 与顾客交互。参加者能够调 用对象,对象也能够告知参 加者,如下图所示。
四、 怎样使用消息进行通信
消息是顺序图活动对象之间通信旳惟一 方式。UML中消息使用了某些简介旳标识符。
消息能够包括条件以便限制它们只有满 足条件时才干发送。条件显示在消息名称上 面旳方括号中,如下图所示:
在UML中,总共有4种类型旳消 息,如下图所示。
到目前为止只看到了一种消息, 即简朴消息(flat message)
旳操作统计下来,以供后来查询。最 终,Engine 直接将成果返回给 ProcessMonitor,由ProcessMonitor将 成果包装,显示给顾客。
六、学习怎样建模顺序图
创建顺序图包括四项任务: • 1)拟定需要建模旳工作流。 • 2)从左到右布置对象。 • 3)添加消息和条件以便创建每
一种工作流。 • 4)绘制总图以便连接各个分图。
2.布置对象
• 建模顺序图旳下一步是从左 到右布置全部旳参加者和对 象,包括要添加消息旳对象 生命线。
3.添加消息和条件
接下来,对每一种工作流 作为独立旳顺序图建模。从基 本旳工作流开始,它是没有犯 错条件,而且需要至少决策旳 工作流。在本例中,基本工作 流是教师成功地检验某个学生 旳分数。如下图所示。
1. 同步消息
同步消息(synchronous message)代表一种操 作调用旳控制流。同步消息旳发送者把控制 传递给消息旳接受者。然后暂停活动,等待 消息接受者旳应答,收到应答后才继续自己 旳操作。
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件概要设计说明书类图顺序图YUKI was compiled on the morning of December 16, 2020软件概要设计说明书................................... 错误!未定义书签。

1.概述.......................................... 错误!未定义书签。

软件设计目标 ................................ 错误!未定义书签。

参考资料 .................................... 错误!未定义书签。

2术语表............................................ 错误!未定义书签。

3用例.............................................. 错误!未定义书签。

4设计概述.......................................... 错误!未定义书签。

简述............................................. 错误!未定义书签。

系统结构设计..................................... 错误!未定义书签。

物理模型:............................. 错误!未定义书签。

软件功能结构图:....................... 错误!未定义书签。

系统层次划分..................................... 错误!未定义书签。

设计用况的类图、顺序图........................... 错误!未定义书签。

市民上报问题................................. 错误!未定义书签。

上级下达命令................................. 错误!未定义书签。

街乡二级平台上报问题......................... 错误!未定义书签。

(监督员)登记问题(接线员上报问题)......... 错误!未定义书签。

值班长核查问题............................... 错误!未定义书签。

约束和假定...................................... 错误!未定义书签。

5非功能性需求...................................... 错误!未定义书签。

软件概要设计说明书1.概述本说明书主要描述朝阳区城市网络化管理信息系统的子系统的各个模块的设计;包括登录模块,登记问题模块,市民上报问题模块,上级下达命令模块,街乡二级平台上报问题模块,核查问题模块,以及立案模块。

将针对上述模块的功能进行面向对象的分析并完成相应用例的顺序图,相应对象的状态图的设计以及系统总体构架和配置。

对系统的性能,可用性等非功能需求也有相应描述,供详细设计人员和项目小组以及用户参考。

1.1软件设计目标我国数字城市技术应用现已逐渐应用到社会的各个领域中。

为了节约大量的人力、物力、财力。

网格管理新模式的提出将解决人们一串串“投诉没门路、解决无期限”的烦恼。

本系统主要实现朝阳区城市网络化管理信息系统中的信息提交子系统功能。

具体针对各个模块进行概要设计,模块化结构更清晰。

1.2参考资料中华人民共和国国家标准:《城市市政监管信息系统技术规范》;《城市市政监管信息化部件和事件分类与编码》;《城市市政监管信息化单元网格划分与编码》;《城市市政监管信息化地理编码》;《软件需求规格说明书》2术语表UML 统一建模语言3用例系统顶级用例图:4设计概述简述本说明书采用的设计方法为面向对象设计法;系统的体系结构为B/S结构;相应技术为 UML_Rational Rose.系统结构设计4.1.1物理模型:配置图:1.节点说明Web服务器:Happy 2005 CPU,512MB内存,20GB*4硬盘;操作系统:Windows XP;数据库服务器: MS SQL Server 2000;浏览器:。

协议:数据库:ADO2. 节点间的连接协议:网络:TCP/IP3.节点的性能要求根据登录权限进入相应角色对应的界面,接线员,市级领导,街乡二级平台,值班长,监督员要进行用户名和口令登录检查。

4.1.2软件功能结构图:登录模块:除市民外,其余角色必须用相应的用户名和密码登录;权限管理:根据登录用户名,分配权限;并根据用户权限进入相应的网页;市民上报问题:市民无需身份验证,可直接填写市民上报问题表单;接线员上报问题:登录成功后,进入接线员上报表单,登记市民所举报的问题并提交;市级领导上报问题:登录成功后,进入市级领导上报问题表单,登记问题并提交;街乡二级平台上报问题:登录成功后,进入街乡二级平台上报问题表单,登记问题并提交;监督员上报问题:登录成功后,进入监督员上报问题表单,登记问题并提交;查询模块:登录成功后,值班长可查询所有问题,并根据问题状态进行相应的处理;值班长发送命令:登录成功后,值班长将待核查的问题以命令形式发送给监督员;监督员核查问题:登录成功后,监督员核查问题并修改核查问题表单;立案模块:值班长登录成功后,根据问题状态进行立案;系统层次划分系统划分为五个层次:用户界面层、专用应用软件层、通用应用软件层、中间层和数据层。

系统层次图:界面层包括登录界面、市民上报问题界面、市级领导上报问题界面、街乡二级平台上报问题界面、监督员上报问题界面、值班长浏览操作界面等用户界面。

专用软件层包括市民上报问题,市级领导上报问题,街乡二级平台上报问题,监督员上报问题,值班长核查问题等处理。

通用软件层包括登录、权限管理、通用查询类。

数据层包括实体类及其相应的服务。

界面层自系统与专用软件层和通用软件层之间是“请求—服务”关系,它不可以直接与数据层发生关系。

专用层与通用层有依赖关系和继承关系。

专用层、通用层与数据层之间是“请求—服务”关系。

设计用况的类图、顺序图4.4.1市民上报问题4.4.1.1 市民上报问题类图,顺序图用例编号:U_01_008 市民上报问题:说明:市民上报问题时,在登录界面里,市民无需登录,点击市民上报直接进入市民上报问题表单,输入上报的问题,点击确认,进行有效性验证,查询问题登记表,检查是否有相同的模糊匹配的记录,如果该问题已存在或是已解决,则返回该问题已存在/已解决对话框;否则进行上报问题处理,修改问题登记表,创建一条问题记录;同时返回提交成功对话框。

市民上报问题用例中的界面类包括:登录界面(Login)市民上报问题表单(PubForm)提交成功对话框(SubSuccessDialog)问题已存在/已解决对话框(ExistDialog)市民上报问题用例中的控制类包括:检查(Check):问题查询,以及输入有效性上报问题处理(Submission)市民上报问题用例中的实体类包括:问题登记表(ProbRecord)顺序图:4.4.1.2边界类市民上报问题界面类的原型如图所示:登录界面原型如下:4.4.1.3实体类ProbRecord类:映射到数据库的问题登记表T-ProbRecord表上职责:通过ADO表单内容进行汇总并在T-ProbRecord表中创建一条问题记录。

属性:操作:提交信息(CREAT)重新填写(REWRITE)4.4.1.4控制类检查类:检查市民填写表单的有效性1)接收市民上报问题表单界面类专递来的表单;2)进行汇总,形成有效数据并检索数据库的T-ProbRecord表,进行模糊查询,如果存在该问题,则显示该问题已存在对话框;3)如果不存在该问题,进行上报问题处理上报问题处理类:处理上报问题1)创建问题记录,对默认值默认处理,对关联项进行匹配。

2)读取问题信息,问题编号自动加一,时间为当前系统时间,当前状态为待核查;3)返回提交成功对话框。

4.4.2上级下达命令4.4.2.1 上级下达命令类图,顺序图用例编号:U_01_009 上级下达命令:说明:上级下达命令时,需要正确登录,输入提交者和密码,点击登陆,进行身份验证,身份验证无误后,进入市级领导上报问题表单,输入上报的问题,点击确认,进行有效性验证,进行上报问题处理,修改问题登记表,创建一条问题记录;同时返回提交成功对话框。

上级下达命令用例中的界面类包括:登录界面(Login)市级领导上报问题表单(LeaderForm)提交成功对话框(SubSuccessDialog)市级领导上报问题用例中的控制类包括:身份验证(UserValidity):身份验证检查(Check):问题查询,以及输入有效性上报问题处理(Submission)市级领导上报问题用例中的实体类包括:用户信息表(T_UserInfo)问题登记表(T_ProbRecord)顺序图:4.4.2.2边界类市级领导上报问题界面类的原型如图所示:登录界面原型如下:4.4.2.3实体类ProbRecord类:映射到数据库的问题登记表T-ProbRecord表上处理同上UserInfo类:映射到数据库的用户信息表T-UserInfo表上职责:根据输入的提交者,密码,到用户信息表中验证用户身份,并根据权限显示相应的表单。

属性:4.4.2.4控制类用户有效性验证类:验证提交者身份1)提交者点击登陆,根据提交者和密码到信息表中验证有效性2)验证通过后根据用户信息表中的用户类型编码调用并显示相应的市级领导上报问题表单。

检查类:检查市级领导上报问题表单的有效性1)接收市级领导上报问题表单界面类专递来的表单;2)进行汇总,形成有效数据;3)进行上报问题处理上报问题处理类:处理上报问题1)创建问题记录,对默认值默认处理,对关联项进行匹配。

2)读取问题信息,问题编号自动加一,时间为当前系统时间,当前状态为已提交;3)返回提交成功对话框。

4.4.3街乡二级平台上报问题4.4.3.1 街乡二级平台上报问题类图,顺序图用例编号:U_01_010 上级下达命令:说明:街乡二级平台上报问题时,需要正确登录,输入提交者和密码,点击登陆,进行身份验证,身份验证无误后,进入街乡二级平台上报问题表单,输入上报的问题,点击确认,进行有效性验证,进行上报问题处理,修改问题登记表,创建一条问题记录;同时返回提交成功对话框。

街乡二级平台上报问题用例中的界面类包括:登录界面(Login)街乡二级平台上报问题表单(LeaderForm)提交成功对话框(SubSuccessDialog)街乡二级平台上报问题用例中的控制类包括:身份验证(UserValidity):身份验证检查(Check):问题查询,以及输入有效性上报问题处理(Submission)街乡二级平台上报问题用例中的实体类包括:用户信息表(T_UserInfo)问题登记表(T_ProbRecord)顺序图:4.4.3.2边界类街乡二级平台上报问题界面类的原型如图所示:登录界面见上4.4.3.3实体类ProbRecord类:映射到数据库的问题登记表T-ProbRecord表上处理同上UserInfo类:映射到数据库的用户信息表T-UserInfo表上处理同上4.4.3.4控制类用户有效性验证类:验证提交者身份1)提交者点击登陆,根据提交者和密码到信息表中验证有效性2)验证通过后根据用户信息表中的用户类型编码调用并显示相应的街乡二级平台上报问题表单。

相关文档
最新文档