《医院自助挂号系统》系统分析实验报告.docx

《医院自助挂号系统》系统分析实验报告.docx

《《医院自助挂号系统》系统分析实验报告.docx》由会员分享，可在线阅读，更多相关《《医院自助挂号系统》系统分析实验报告.docx（16页珍藏版）》请在冰豆网上搜索。

《医院自助挂号系统》系统分析实验报告

实验报告□实践报告□

课程名称：

系统分析与设计

实验、实践名称：

《医院自助挂号系统》

实验、实践地点：

专业班级：

学号：

学生姓名：

指导教师：

20**年11月19日

一、实验目的

通过《系统分析与设计》实验，使学生在实际的案例中完成系统分析、设计的主要步骤，在实践中熟悉信息系统分析与设计的规范及信息系统开发的相关应用软件；加深对信息系统分析与设计课程的基础理论、基本知识的理解；树立正确的分析设计思想，提高系统分析、设计的实践能力及撰写书面文件的能力。

二、实验要求

要求学生以个人为单位自选题目，班内选题不重复；对所选项目进行调查，写出300字以上的系统描述；利用系统分析与设计的基本原理、方法进行系统分析、设计，使用UML语言构建该系统的分析、设计模型，并完成实验报告；实验报告以纸质版（A4）提交。

三、实验主要设备：

台式或笔记本计算机

四、实验内容

1选题及项目背景

选题：

医院自助挂号系统

项目背景：

当今人们对健康逐渐重视起来，造成我国目前大型医院排队挂号队伍长，等待时间长，同时会造成医院拥挤堵塞。

所以医院引进自助挂号机来解决这一现状。

自助挂号机通过结合触摸屏等硬件技术并与医院现有信息系统实现对接可以满足病人对于医院的自助挂号，帮助医院优化业务流程，提升医院日常运营效率和服务质量。

2定义

某位病人在医院使用自助挂号机进行挂号。

在主页面点击[自助挂号]按钮，进入挂号系统页面。

将身份证放在身份证感应区，系统将读取病人信息。

读取完毕后进入就诊科室页面，如果科室有子科室，需进一步选择子科室。

选择科室后，进入选择医生界面，然后确定就诊时间。

系统生成就诊信息，等待病人确认，病人确认后，进行付款。

支付方式为银行卡支付。

在银行卡插口插入银行卡，系统进行识别，若识别失败，提示插入正确的银行卡。

识别成功后提示病人输入密码，病人输入密码后，系统进行确认，若输入密码错误，提示错误，并返回输入密码界面。

（若卡中金额不足，系统提示余额不足并吐出银行卡。

）支付成功后打印自助挂号单，用户取走挂号凭条后，机器将银行卡吐出，系统返回主界面。

3参考资料

《系统分析与设计》

4系统分析与设计

4.1需求分析

4.1.1识别参与者

病人、系统管理者

4.1.2对需求进行捕获与描述

用例名称：

点击【自助挂号】按钮执行者：

病人

目的：

进入挂号系统页面

用例名称：

将身份证放在身份证感应区执行者：

病人

目的：

让系统读取信息

用例名称：

读取病人信息执行者：

系统管理者

目的：

读取病人的信息

用例名称：

切换页面执行者：

系统管理者

目的：

切换到正确的页面

用例名称：

选择科室执行者：

病人

目的：

选择就诊的科室

用例名称：

选择医生执行者：

病人

目的：

选择就诊的医生

用例名称：

选择就诊时间执行者：

病人

目的：

选择合适的就诊时间

用例名称：

生成就诊信息执行者：

系统管理者

目的：

生成病人的就诊信息

用例名称：

确认就诊信息执行者：

病人

目的：

确认自己的就诊信息是否正确

用例名称：

付款执行者：

病人

目的：

支付挂号的费用

用例名称：

插卡执行者：

病人

目的：

插入银行卡

用例名称：

识别银行卡执行者：

系统管理者

目的：

识别插入的卡是否为银行卡

用例名称：

提示执行者：

系统管理者

目的：

提醒用户进行操作

用例名称：

输入密码执行者：

病人

目的：

输入银行卡密码进行支付

用例名称：

验证密码执行者：

系统管理者

目的：

验证银行卡密码是否正确

用例名称：

吐出银行卡执行者：

系统管理者

目的：

将银行卡从机器中吐出

用例名称：

打印自助挂号单执行者：

系统管理者

目的：

打印病人的自助挂号单

用例名称：

取走凭条执行者：

病人

目的：

用户取走挂号单

（内容要求2：

选择其中一个用例（如确认就诊信息）给出其用例描述。

100.1

用例ID号及用例名

确认就诊信息

100.2

用例概述

该用例描述一个自助挂号中，用户选择科室、医生以及就诊时间后，系统自动生成就诊信息，用户确认成功后，进入支付环节。

支付成功后打印挂号凭条

100.3

参与者：

病人

101.4

前置条件（Pre-Conditions）

用户选择科室、医生以及就诊时间并且系统生成就诊信息

100.5

后置条件（Post-Conditions）

进入支付环节，支付成功后打印挂号凭条

100.6

事件流

100.6.1

基本事件流

（BasicFlow）

1）用户进入自助挂号界面，提交身份信息

2）选择科室、医生、就诊时间

3）系统生成就诊信息后确认就诊信息

4）用银行卡支付挂号费用

5）支付成功后打印出自助挂号单

6）用户取出挂号单后，取走银行卡

100.6.2

扩展事件流（AlternativeFlows）

1.若选择的科室有子科室，进一步选择子科室

2.插入错误的卡，系统提示错误，并重新插入正确的卡

3.银行密码输入错误，系统提示错误，并重新输入密码

4.若卡中余额不足，系统提示余额不足，吐出银行卡

）

4.1.3用例图

图1-1用例图

4.1.4分析与讨论

1）建模用例图的步骤、方法？

1.确定系统的边界和范围；（方法：

分析系统内部元素，把系统内部元素和外部事物划分开）

2.识别系统的参与者；

3.发现用例；

4.描述用例及确定用例关系；（方法：

对用例概要描述；对用例详细描述。

根据用例事件流，将公共行为抽取出来，已包含关系构建用例关系；变化部分，抽取出来，放到扩展用例中）

5.建立用例图；

6.定义用例图的层次结构；

2）如何识别系统的参与者？

应该如何划分用例，应注意哪些问题？

通过回答以下问题来识别系统的参与者：

1.谁使用系统的主要功能？

2.谁改变系统的数据？

3.谁从系统中获取数据？

4.谁支持、维护系统？

5.谁需要借助系统的支持来完成工作？

6.系统需要操纵哪些硬件？

7.系统需要和哪些外部系统交互？

8.谁对系统运行结果感兴趣？

划分用例：

1.每个参与者打算在这个系统里做些什么事情？

2.参与者使用本系统要实现的目标是什么？

3.参与者是否会在系统中创建、修改、删除、访问、存储数据？

如果是，如何来完成这些操作？

4.参与者是否会将外部的某些事件通知给该系统？

3）心得

用例图主要用来描述用户、需求、系统功能单元之间的关系。

它展示了一个外部用户能够观察到的系统功能模型图。

用途：

帮助开发团队以一种可视化的方式理解系统的功能需求。

用例图所包含的元素如下：

1.参与者表示与您的应用程序或系统进行交互的用户、组织或外部系统。

用一个小人表示。

2.用例用例就是外部可见的系统功能，对系统提供的服务进行描述。

用椭圆表示。

3.子系统用来展示系统的一部分功能，这部分功能联系紧密。

4.关系用例图中涉及的关系有：

关联、泛化、包含、扩展；

a.关联表示参与者与用例之间的通信，任何一方都可发送或接受消息。

b.泛化就是继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。

子用例可以使用父用例的一段行为，也可以重载它。

父用例通常是抽象的。

c.包含包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤；

d.扩展扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。

e.依赖表示源用例依赖于目标用例；

4.2建立对象模型

4.2.1候选类的数据字典

类

定义

病人

来医院进行自助挂号看病的人

自助挂号机

进行挂号操作、打印挂号凭条

挂号凭条

凭借挂号凭条才可进行就诊

科室

供选择的内容

医生

供选择的内容

就诊信息

包括选择科室、选择医生、选择时间

子科室

科室下还另一个更细节的科室

时间

供选择的内容

4.2.2定义类

（内容以“书籍信息”类为例列出该类的属性和操作如下：

“病人”类

•属性

姓名（name）：

文本（String）

性别（sex）：

文本（String）

年龄（age）：

整型（int）

联系电话（TelNum）:

整型（int）

•操作

点击按钮

放置身份证

选择就诊信息

确认就诊信息

付款

插银行卡

输入密码

取走挂号凭条

“病人就诊信息”类

•属性

科室

医生

时间

“科室”类

•属性

名称

医院系统编码

科室唯一标识

最大预约量

“子科室”类

•属性

•操作

“医生”类

•属性

姓名

医生编码

医生唯一标识

出诊开始时间

出诊结束时间

最大预约量

“就诊时间”类

•属性

时间

“自助挂号单”类

•属性

病人姓名

选择科室名称

选择医生姓名

选择就诊时间

收取费用

“自助挂号机”类

•操作

打印自助挂号单

吐出银行卡

自助挂号机屏幕”类

•操作

提示

切换页面

4.2.3绘制类图

（在类图中标示出类的属性、操作、类之间的关系及多重性，并对所给出的类图解释说明。

）

图1-2类图

病人就诊信息必须由就诊时间、医生、科室组成所以它们之间是依赖的关系，病人也是依赖自助挂号机才能完成一切操作。

一个病人生成一个就诊信息，故只有一个自助挂号单。

但是一个自助挂号机可以有多个病人的就诊信息，生成多个自助挂号单。

4.2.4包图

对于大型复杂系统，常需要把大量的模型元素用包组织起来，以方便处理。

对所选系统的类进行分组，以便更清晰地了解系统的结构。

图1-3包图

4.2.5分析与讨论

1）建模类图的步骤、方法？

构建类图的步骤：

1.确定类；（方法：

行为分析、名词识别法、CRC分析法、根据边界类、控制类、实体类的划分、参考设计模式确定、通过领域进行分析等）

2.识别类的属性和操作；（方法：

结合需求陈述、领域知识和常识以及经验等）

3.识别类之间的关联；（方法：

使用普通关联列表的方法）

4.定义类的结构和层次。

2）识别类有哪些方法，你是如何识别类的？

行为分析、名词识别法、CRC分析法、根据边界类、控制类、实体类的划分、参考设计模式确定、通过领域进行分析等。

我通过名名词识别法确定类。

3）解释关联的多重性？

如何确定类的属性、操作、类之间的关联关系、组织类之间的继承？

关联的多重性：

关联表示了对象间的结构关系，在建模过程中，通常需要说明一个关联实例中有多少个相互连接的对象。

 确定类的属性：

从常识性、专业性、功能性、存储性、操作性、标志性、关联性发现和确定类的属性，进而筛选类的属性； 

 确定类的操作：

综合对象模型、动态模型和功能模型，确定类的操作； 

 确定类之间的关联关系：

使用普通关联列表的方法帮助发现关联。

并分析关联的多重性。

 组织类之间的继承：

自顶向下和自底向上的方法。

4.3系统动态分析

系统的动态行为模型由交互图（顺序图和协同图）、状态机图和活动图表达。

在系统的分析和设计中应当对主要的UseCase和对象类绘制这些图形，以便分析系统的行为，印证和修改系统的静态结构，满足用户的需求，达到系统的目标。

4.3.1顺序图

对病人进行付款的顺序活动，银行卡插口插入银行卡，系统进行识别，若识别失败，提示插入正确的银行卡。

识别成功后提示病人输入密码，病人输入密码后，系统进行确认，若输入密码错误，提示错误，并返回输入密码界面。

支付成功后打印自助挂号单，

图1-4顺序图

4.3.2通信图

图1-5通信图

4.3.3活动图

活动图的主要作用是表示系统的业务工作流和并发处理过程。

针对自选系统主要的业务工作流绘制活动图。

绘制活动图需要确定参与活动的对象、动作状态、动作流，以及对象流。

图1-6活动图

4.3.4状态图

状态机图表现一个对象（类）的生命史。

对于一些实现重要行为动作的对象应当绘制状态机图。

绘制状态机图需要确定一个对象的生命期可能出现的全部状态，哪些事件将引起状态的转移，将会发生哪些动作。

图1-7状态图

4.3.5分析与讨论

比较顺序图与通信图、活动图与状态图的应用。

 顺序图：

描述的是参与交互的对象及对象之间消息交换的顺序，用来表示用例中的行为顺序。

 通信图：

强调发送和接收消息的信息的对象及其组织结构的交互图，用以描述对象以及对象之间的交互关系。

活动图：

用来描述达到一个目标所实施一系列活动的过程，描述了系统的动态特征。

  状态图：

描述系统中类和对象随时间变化的动态行为。

状态图：

描述某一对象的状态转化的，它主要表现的是该对象的状态。

从状态图中可以看出，该对象在接受了外界的某种刺激之后，会做出什么样的反应。

描述的是一个对象的事情。

可以说是对类图的一种补充，帮助开发者完善某一类。

4.4系统设计

掌握系统的架构设计、资源设计及设计模式的应用。

4.4.1构建系统体系结构的初始逻辑设计包图。

4.4.2构建系统的物理模型

构建系统体系结构的物理设计构件图及部署图。

构件图：

系统实现的源代码、二进制码、执行码可以按照模块化的思想，用构件分别组织起来，明确系统各部分的功能职责和软件结构。

图1-8构件图

部署图

图1-9部署图

4.5对象模型设计

掌握设计类的识别方法；掌握类的职责分配方法，并精化类的属性和操作；能够确定类的接口、优化类间的关系并将设计类图分组成包。

4.5.1构建设计类图

图1-10类图

4.5.2构建类包图

图1-11类包图