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

合集下载

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

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

软件项目概要设计说明书模板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.问题定义2.可行性研究3.需求分析4.总体设计(概要设计)5.详细设计6.编码和单元测试7.综合测试8.软件维护。

下面我们就说说各个阶段中与图的难解难分。

1. 问题定义问题定义阶段主要是根据用户的需求来定义用户需要解决的问题,用户要实现哪些功能。

2. 可行性研究可行性研究阶段就是看是否有一种使其在最小的代价,尽可能短的时间内,利益最大化的情况下解决问题的方案。

这个阶段的分析主要涉及以下几个图形工具。

2.1 系统流程图系统流程图是描述系统物理模型的一种传统工具。

它是表达数据在系统各部件之间流动的情况,而不是对数据加工处理的控制过程,它是物理数据流图而不是程序流程图。

系统流程图形象的呈现了软件的功能,即使不懂软件的人也可以轻松的看懂,可以说它是软件设计师与用户之间沟通、交流的有效工具。

2.2 数据流图数据流图是从数据传递和加工角度,以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程,是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。

如果说系统流程图能让用户更好的明白系统的功能,那么数据流图则让用户更加明白系统的工作原理。

2.3 数据字典数据字典就是数据的信息的集合,也可以说就是对上面提到的数据流图中的所有元素的定义的集合。

概要设计说明书实例

概要设计说明书实例
1引言3
1.1编写目的3
1.2背景3
1.3定义3
1.4参考资Βιβλιοθήκη 32总体设计32.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
+读取用户权限(in用户ID):Data::权限实体类
页面显示全部权限内容:调用Service::权限的查询全部权限或通过所属系统查询全部权限,将权限数据显示到页面上。
通过所属系统查询全部权限:调用Service::权限的通过所属系统查询全部权限,读取某系统下的全部权限数据。
UI:员工管理
+通过D查询员苒口员工!口):Data员工实体类
+多条件查询员®查询条件对象Data:员工实体类
+查询全部员工:Data员工实体类
+增加员单口Data员工实体类:boolean
+修改员单口Data员工实体类:boolean_
+删除员单口员工!口):boolean
+员工修改登录密码n员工D,由密码:boolean
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

软件开发概要设计说明书

软件开发概要设计说明书

概要设计说明书1引言1. 1.1编写目的概要设计主要是利用比较抽象的语言对整个需求进行概括,确定对系统的物理配置,确定整个系统的处理流程和系统的数据结构,接口设计,人机界面,实现对系统的初步设计。

我们根据需求分析得到的数据流图,将之转化为软件结构和数据结构,建立起目标系统的逻辑模型。

使软件编程人员能对目标系统有一致的认识。

1.2背景待开发的软件系统的名称:宿舍管理系统项目的任务提出者:李剑项目开发者:李剑、杨民岱、娄小敏、田海燕、沈大正用户:在校全体师生及相关工作人员实现该软件的计算机网络:校园网1.3定义 : —项微软公司的技术,是一种使嵌入网页中的脚本可由因特网服务器执行的服务器端脚本技术。

指Active Server Pages (动态服务器页面),运行于IIS之中的程序。

1.4参考资料【1】赵绪辉张树明编渤海大学信息科学与工程学院《软件工程》课程设计指导用书第五版【2】张海藩《软件工程》清华大学出版社第二版【3】张尧学《web数据库系统开发教程》清华大学出版社第三版2总体设计2.1需求规定本系统主要的输入输出项目有: 输入:说明对本系统的主要的输入输出项目、处理的功能性能要求。

数据可靠性:在应用系统投入运行5年生命周期内数据不得丢失;一旦数据转为历史记录后任何人不得更改。

应用程序试用期结束后,程序运行过程中不允许出现程序逻辑与算法错误。

程序系统运作在运作过程中,由于操作错误或输入/输出数据溢出时,不应死机而应提示故障原因,然后以正常出口退出当前操作环境。

非授权用户不得进入程序系统。

无修改权的用户不得修改档案和更新以及执行处理功能。

2.2运行环境服务器配置如下:a. 处理器型号及内存容量:In tel酷睿2四核Q8300(盒),金士顿4GB DDR3 800 (2 条组双通道)b. 外存容量、联机或脱机、媒体及其存储格式,设备的型号及数量:硬盘:WD 1TB7200 转16MB(串口/YS)c. 输入及输出设备的型号和数量,联机或脱机:键盘,鼠标,显示器各一个。

软件概要设计 详细设计 软件设计 用户手册说明全套

软件概要设计 详细设计 软件设计 用户手册说明全套

软件概要设计、详细设计、软件设计、用户手册说明1 简介1.1 目的这部分要描述文档的目的。

应该指明读者。

1.2 范围1.2.1 软件名称对软件命名1.2.2 软件功能解释软件产品将完成或不完成的功能(可以直接描述也可以参考相关文档)1.2.3 软件应用描述软件的应用领域(可直接描述也可以参考其他软件文档)2 第0层设计描述2.1 软件系统上下文定义本节描述待开发软件系统与外部实体的关系,可以使用系统结构图来描述系统结构和交互关系。

外部实体属性描述只限于软件设计和描述相关的属性。

考虑到描述的完整性,可参考相关软件实体文档,如OS程序员手册。

2.2 设计思路(可选)2.2.1 设计可选方案对本软件系统的几种设计方案进行分析、比较,并确定所采用的方案。

2.2.2 设计约束1. 遵循标准描述本软件所遵循的标准、规范2. 硬件限制描述本软件系统实现的硬件限制3. 技术限制描述本软件的技术限制2.2.3 其他描述其他有关的设计考虑3 第一层设计描述3.1 系统结构如果本文档是针对增强开发/小特性的设计,继承了原有的系统结构,那么应拷贝原有的系统结构说明,如系统结构图和相应的文字说明,然后在一层设计中明显标识出新增功能在原有系统结构中的位置(属于原来哪一个模块的新增功能,与原有各模块之间有什么交互)。

在后续的业务流程说明、模块分解描述、依赖性描述和接口描述中,如果与本次增强开发/小特性无关的,可以不再重复描述,如果有关联的,应该拷贝原有的设计说明,在此基础上再说明更改的内容。

3.1.1 系统结构描述这里要描述软件系统的总体结构,可以使用结构图、层次分解图或包图来描述,并应说明系统结构划分的原则(例如,基于标准、协议所规定的体系结构,来自于分析模型的结果,或者基于原有体系结构的结果)。

对于使用分析模型的体系结构,应说明分析类的职责及相互关系。

3.1.2 业务流程说明描述系统架构模块/分析类之间的动态交互,来说明用例模型中的典型用例场景,以体现系统功能是如何实现的。

第13讲 UML详细设计-顺序图

第13讲 UML详细设计-顺序图
对象名匿名对象匿名对象对象的左右排列位置对象的左右排列位置对象的左右顺序并不重要但是为了图面的清晰整洁起见通常应遵循以下两个原则对象的左右顺序并不重要但是为了图面的清晰整洁起见通常应遵循以下两个原则11把交互频繁的对象尽可能地靠拢把交互频繁的对象尽可能地靠拢22把初始化整个交互活动的对象有时是一个参与者放置在最左边把初始化整个交互活动的对象有时是一个参与者放置在最左边生命线生命线表示对象存在的时间对象下面一条虚线表示
时序图中,消息的阅读顺序是严格自上而下的
消息的类型:
在UML中,总共有4种类型的消息,如下图所示。 到目前为止只看到了一种消息,即简单消息(flat message)。
(1). 同步消 息 同步消息(synchronous message)代表一个操作调用的控制流。 同步消息的发送者把控制传递给消息的接收者,然后暂停活动,等 待消息接收者的应答,收到应答后才继续自己的操作。
以使用顺序图进一步阐明和实现。
顺序图刻画了用例具体实现的流程,比活动图更能 够表示细节,因此适用于详细设计。
顺序图与用例图和类图的关系
UML
-5-
三、顺序图的标记符 顺序图有两个主要的标记符:活动对象和这些活动对象之间 的通信消息。活动对象可以是任何在系统中扮演角色的对象,不 管它是对象实例还是参与者,如下图所示。
练习:建模在图书馆网上借书和续借书的顺 序图 包括:登陆、个人借阅信息界面、续借(图 书是否过期,是否续借过)
3.分支和从属流 有两种方式来修改顺序图的控制流:使用分支和使用从属 流。控制流的改变是由于不同的条件导致控制流走向不同的道 路。 分支是指从同一点发出的多个消息并指向不同的对象,根据 条件是否互斥,可以有条件和并行两种结构。
注意消息的开始位置是相同的,分支消息的结束“高度”也是相 等的。这说明在下一步中,其中之一将会执行,如下图所示。

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

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





































登录模块:除市民外,其余角色必须用相应的用户名和密码登录; 权限管理:根据登录用户名,分配权限;并根据用户权限进入相应的网页; 市民上报问题:市民无需身份验证,可直接填写市民上报问题表单; 接线员上报问题:登录成功后,进入接线员上报表单,登记市民所举报的问题并提交; 市级领导上报问题:登录成功后,进入市级领导上报问题表单,登记问题并提交; 街乡二级平台上报问题:登录成功后,进入街乡二级平台上报问题表单,登记问题并提交; 监督员上报问题:登录成功后,进入监督员上报问题表单,登记问题并提交; 查询模块:登录成功后,值班长可查询所有问题,并根据问题状态进行相应的处理; 值班长发送命令:登录成功后,值班长将待核查的问题以命令形式发送给监督员; 监督员核查问题:登录成功后,监督员核查问题并修改核查问题表单; 立案模块:值班长登录成功后,根据问题状态进行立案;
包括
登录模块, 登记问题模块,市民上报问题模块,上级下达命令模块,街乡二级平台上报问题
模块, 核查问题模块, 以及立案模块。 将针对上述模块的功能进行面向对象的分析并完成相
应用例的顺序图, 相应对象的状态图的设计以及系统总体构架和配置。
对系统的性能, 可用
性等非功能需求也有相应描述,供详细设计人员和项目小组以及用户参考。
进行上报问题处理,修改问题登记表,创建一条问题记录;同时返回提交成功对话框。

软件概要设计说明书范例

软件概要设计说明书范例

XX概要设计说明书文档修改记录填写说明1.系统结构的定义本体系对整个软件系统按如下结构方式进行划分: 系统( 子系统( 模块( 子模块其中:(1)“系统( 子系统”划分属于“系统设计”, 在系统设计说明书中予以描述。

(2)“子系统( 模块”划分属于“概要设计”, 在本说明书中予以描述。

(3)“模块( 子模块”划分属于“详细设计”, 在详细设计说明书中予以描述。

如果系统相对简单, 可以省略“子模块”这一层次。

2.如果填写了系统设计说明书,则在本说明书中略过“系..子系统”划分的相关内容(即第2章)。

3.如果系统相对简单,不需要做“系..子系统”划分,这种情况下,取消填写系统设计说明书,只须填写本说明书,直接套用“子系..模块”划分(即第3章)进行“系..模块”划分(把其中“子系统”一词替换为“系统”),并删除本说明书中“系..子系统”划分的相关内容(第2章)。

目录1.简介 (1)1.1.背景和目的 (1)1.2.范围 (1)1.3.术语和缩略语 (1)2.系统总体设计 (1)2.1.任务概述 (2)2.1.1.目标 (2)2.1.2.需求概述 (2)2.2.设计概述 (2)2.2.1.总体约束 (2)2.2.2.系统外部接口 (2)2.2.3.设计方案概述 (2)2.3.系统架构设计 (3)2.3.1.系统的逻辑架构设计 (3)2.3.2.系统的物理架构设计 (5)2.4.子系统定义 (5)2.4.1.子系统列表 (5)2.4.2.子系统间关系 (6)3.子系统1设计 (6)3.1.任务概述 (7)3.1.1.目标 (7)3.1.2.需求概述 (7)3.2.设计概述 (7)3.2.1.总体约束 (7)3.2.2.子系统外部接口 (8)3.2.3.设计方案概述 (9)3.3.子系统架构设计 (9)3.4.模块定义 (11)3.4.1.模块列表 (11)3.4.2.模块间关系 (11)3.4.3.模块描述 (11)4.非功能性需求的实现方案 (13)6.1.性能的考虑 (13)6.2.兼容性的考虑 (13)6.3.安全的考虑 (13)6.4.可移植性的考虑 (13)6.5.集成与测试的考虑 (14)6.6.可扩展性的考虑 (14)6.7.可靠性的考虑 (14)6.8.可维护性的考虑 (14)5.难点及解决方案 (14)6.参考资料 (15)7.附录 (15)1. 简介1.1. 背景和目的1.2. 本文档编制的目的是说明对软件系统的设计考虑, 包括软件系统的基本处理流程, 软件系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等, 为软件的详细设计奠定基础。

软件概要设计说明模板-类设计版

软件概要设计说明模板-类设计版

修订记录注:修订记录在体系文件发布后换版时使用,修订状态栏填写:A—增加,M—修改,D—删除目次1 范围 (2)1.1 标识 (2)1.2 系统概述 (2)1.3 文档概述 (2)2 引用文档 (2)3 CSCI设计决策 (2)3.1 假设 (2)3.2 系统体系结构 (3)3.3 软件体系结构 (3)3.4 设计决策 (3)3.4.1 输入/输出设计决策 (4)3.4.2 CSCI行为设计决策 (4)3.4.3 CSCI数据显示设计决策 (4)3.4.4 CSCI安全性设计决策 (4)3.4.5 CSCI保密性设计决策 (5)3.4.6 其他CSCI级设计决策 (5)4 CSCI体系结构设计 (6)4.1 CSCI包汇总 (6)4.2 CSCI类汇总 (6)4.3 CSCI包 (7)4.3.1 PAK_MMI_XX(主体框架包) (7)4.3.2 PAK_MMI_XX(UI包) (8)4.4 执行方案 (8)4.4.1 XX功能/业务 (8)4.5 接口设计 (9)4.5.1 外部接口 (9)4.5.2 内部接口 (10)5 用户界面设计(可选) (11)5.1 应当遵循的界面设计规范 (11)5.2 界面信息汇总 (11)5.3 主界面 (11)5.3.1 XX主界面 (11)5.4 界面资源设计(可选) (12)5.4.1 图标资源 (12)5.4.2 图像资源 (12)5.4.3 界面组件 (12)6 数据(库)结构设计(可选) (12)6.1 逻辑结构设计要点 (12)6.2 物理结构设计要点 (13)7 配置文件设计(若有) (13)7.1 XX配置文件 (13)7.2 XX配置文件 (13)8 部署设计 (13)8.1 设计部署 (13)8.2 物理部署 (13)9 运行设计(可选) (14)9.1 运行软部件组合 (14)9.2 运行控制 (15)9.3 运行时间 (16)10 性能设计 (16)10.1 XX性能 (16)11 系统出错处理设计 (16)11.1 出错信息 (16)11.2 补救措施 (17)11.3 系统维护设计 (17)11.4 错误处理设计 (17)12 CSCI详细设计 (17)13 需求可追踪性 (17)14 注释 (18)图 1 XX系统体系结构图 (3)图 2 XX软件体系结构图 (3)图 3 CSCI体系结构图 (6)图 4 XX包中类关系图 (8)图 5 XX用例时序图 (9)图 6外部接口示意图 (10)图7 XX图 (11)图8数据库逻辑结构图 (12)图 9 XX软件物理部署图 (14)图 10运行包组合图 (15)图 11 运行控制图 (16)表1 XX软件安全性设计决策表 (5)表2 XX软件保密性设计决策表 (5)表3XX软件包汇总表 (6)表4 XX软件类汇总表 (7)表 5 API接口设计表 (10)表 6 信息接口设计表 (10)表 7 信息接口设计表 (10)表8 XX软件界面汇总表 (11)表9XX表字段结构 (13)表9 XX软件设计部署表 (13)表10 XX软件物理部署表 (14)表11 需求追踪表(正向) (17)表12 需求追踪表(逆向) (17)1 范围1.1 标识本条应描述本文档所适用系统和软件的完整标识,适用时,包括其标识号、名称、缩略名、版本号和发布号。

按图索骥---软件的设计图纸(用例图,类图,状态图,活动图,顺序图)

按图索骥---软件的设计图纸(用例图,类图,状态图,活动图,顺序图)

按图索骥---软件的设计图纸序:我一直以为,在软件设计中,各种图要比文档重要的多。

图可以更加直接的反应软件的构造。

尤其是在面向对象的软件设计中。

图可以让我们直观的了解各个类和对象直接的交互和关系。

1、用例图定义:展示系统中参与者与用例之间的关系我的理解:用例图是根据需求分析得到的,也是软件设计中的第一张图纸。

描述了软件系统的全部用户(角色)和全部功能点(业务需求),以及他们之间的关系。

也是软件开发中最重要的一张图纸。

用例准则:用例描述了为参与者提供可测量的价值的一个动作顺序,如:提取资金,登记文件。

参与者准则:参与者是和系统进行一次或多次交互的某个角色,它可以是人,组织,进程或者外部系统,如:客户,学生,付款机技巧:通过竖排用例,隐含表达用例之间的时间顺序。

用例名以意义明确的动词开头。

主要参与者放在图的左上角图例:2、类图定义:类图展示的系统中的类,类之间的相互关系,类的方法和属性。

理解:根据用例图,可以基本上设计出系统的类和他们的之间的关系。

类图描述的就是类的静态结构类关系:关联:关联指的是类之间的特定的对应关系,在UML中拥戴实现的箭头表示。

按照类之间的数量对比,关联可分为以下3种。

聚合:聚合指的是整体与部分之间的关系,在UML中用带实线的菱形箭头表示。

例如台灯和灯泡之间就是聚集关系。

当台灯类(ReadingLamp类)由灯泡类(Bulb类)和Circuit类聚集而成时,在ReadingLamp类中应该包含Bulb类和Circuit类型的成员变量。

聚集关系中,子系统允许被拆卸和替换。

例如:电灯和灯泡Bulb bulb1 = new Bulb(); //创建第一个灯泡Bulb bulb2 = new Bulb(); //创建第二个灯泡ReadingLamp lamp = new ReadingLamp(bulb1); //创建的时候使用第一个灯泡lamp.setBulb(bulb2); //创建以后还可以换成第二个灯泡组合:是关联关系的一种,是比聚集关系强的关联关系。

  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)验证通过后根据用户信息表中的用户类型编码调用并显示相应的街乡二级平台上报问题表单。

相关文档
最新文档