UML电梯系统建模
- 格式:docx
- 大小:137.09 KB
- 文档页数:10
【UML⽤例图实例】电梯控制系统⽤例图电梯控制系统⽤例图⼀、案例要求设计电梯控制系统⽤例图,写出其中三个⽤例的描述每部电梯轿厢内都有楼层按钮,每⼀楼层有⼀组上下⾏按钮,乘客进⼊电梯后按下楼层按钮,按钮被按下时会闪亮,然后通知电梯运⾏到⽬的层,等电梯到了⽇的层后,按钮停⽌闪亮。
乘客在必要时候按下紧急救助按钮,该按钮会⾃动发出电梯需要技术修复的求救信号。
技术⼈员可以通过⼀个控制键来激活或者停⽌电梯所有楼层按钮。
处于安全考虑,只有保安可以通过⼀个控制键打开地下室楼层按钮,所有的电梯都是通过中⼼机房控制。
⼆、案例设计三、案例描述描述项说明⽤例名称指定楼层⽤例描述当乘客进⼊电梯时就是这个⽤例的开始。
它指定了乘客想要去往的楼层,当乘客按下所选择的楼层按钮后这个案例就结束了参与者乘客优先级1前置条件乘客进⼊电梯后置条件电梯接收信号基本操作流程1、乘客进⼊电梯 2、乘客选择想去的楼层 3、到达乘客所选楼层乘客离开电梯可选操作流程1、乘客进⼊电梯选择⼀个想去楼层 2、乘客选择多个楼层 3、乘客进⼊电梯电梯故障不能选择楼层被泛化的⽤例⽆被包含的⽤例⽆被扩展的⽤例⽆描述项说明⽤例名称接受救助信号⽤例描述乘客进⼊电梯发⽣紧急情况,乘客按下紧急求救按钮申请救援,此时就是这个⽤例的开始,电梯发送乘客的求救信号,保安接收到乘客的求救信号,⽤例结束。
参与者保安优先级1前置条件乘客寻求救助后置条件⽆基本操作流程1、乘客进⼊电梯 2、乘客在电梯中发⽣紧急事件按下电梯⾥紧急求救按钮 3、电梯发送乘客的求救信号 4、保安接收到乘客的求救信号可选操作流程1、乘客按下紧急求救按钮,保安接收到求救信号被泛化的⽤例⽆被包含的⽤例⽆被扩展的⽤例⽆描述项说明⽤例名称控制电梯⽤例描述当乘客在电梯中遭遇紧急情况时,保安接收到乘客的求救信号是此⽤例的开始此时联系技术⼈员控制电梯来选择是激活所有楼层按钮还是停⽌所有楼层按钮⽤例结束参与者技术⼈员优先级1前置条件保安接收信号后置条件⽆基本操作流程1、当乘客在电梯中遭遇紧急情况2、保安接收到乘客的求救信号3、技术⼈员控制电梯可选操作流程1、按下电梯控制按钮激活所有楼层2、按下电梯按钮停⽌所有楼层流程1、按下电梯控制按钮激活所有楼层2、按下电梯按钮停⽌所有楼层被泛化的⽤例⽆被包含的⽤例1、激活楼层按钮2、停⽌楼层按钮被扩展的⽤例⽆描述项说明。
电梯简易UML图⼀、⾯向对象技术概述软件危机:1.软件开发过程中出现的难题:复杂程度⾼、研制周期长、正确性难以保证2.表现形式:需求不明确、变更过多,开发进度难以控制;软件成本增加,但质量差;维护困难3.原因:需求不充分,⽆计划性;开发过程不规范;软件⽆评测⼿段4.解决途径:加强软件开发过程管理;推⼴使⽤开发软件的成功技术、⽅法和⼯具软件开发的现状:1.软件⼯程学科不断发展2.软件危机依然存在3.中⼩型软件开发较为成熟,⼤型的仍存在问题常⽤软件开发⽅法:1.瀑布模型2.快速原型3.螺旋模型软件⼯程的⽬的:在规定的时间、规定的费⽤内开发出满⾜⽤户需求的(低错误率,易⽤,可维护,课重⽤,可移植)⾼质量软件系统。
软件与硬件的区别:1.产品需求2. ⽣产⽅式3. 表现形式4. 维护⽅式软件复杂性原因:1.现有硬件系统体系结构造成的2.软件开发很难描述软件的本质规律和特征3.软件系统中各元素之间的关系具有不确定性4.软件需求的不断变化5.软件⽣命周期中需要适应不同硬件环境基本⽅法:1.分解,“分⽽治之”2.抽象,抽取本质特征(过程抽象,和数据抽象)3.模块化,⾼内聚,低耦合4.信息隐藏结构化VS⾯向对象⾯向对象的优点1.易于理解,直接模拟问题空间中的对象属性和⾏为2.稳定性较⾼、适应性好(⽤较稳定的把不稳定的包起来)3.可靠性⾼,灵活性好,可复⽤封装提供两种保护:1.保护对象,防⽌直接访问对象内部细节2.保护客户,防⽌对象实现部分的变化影响客户对象消息是类与类之间通信的桥梁,包括:1.同步消息,请求者需要等待响应者返回2.异步消息,请求者不需要等待响应者返回,发出消息后可以继续⾃⼰的⼯作⼆、 UML概述Unified Modeling Language:1.U: 统⼀各种表⽰有差别的建模⽅法,并集其所长。
2.M: 模型从全局上把握系统的全貌机器部件之间的关系3.L: 是⾯向对象的建模语⾔UML是⼀个通⽤的、可视化的建模语⾔标准,可以⽤来可视化、描述、构造、和⽂档化软件系统的各种⼯作UML的特点:1.统⼀的标准2.⾯向对象3.可视化4.独⽴于开发过程,可适⽤于不同软件过程5.概念明确,表⽰简洁,结构清晰,容易学习掌握UML构成:构造块,UML规则,公共机制构造块:建模元素,模型主体,包括事物,关系,图a.事物:(1)结构事物:类、接⼝、⽤例、组件、节点等(2)⾏为事物:交互、状态机(3)分组事物:把语义上相关的建模元素分组为内聚单元(4)注解事物:捕获特殊信息b.关系(1)关联对象间的⼀组链接(2)依赖事物的改变引起依赖事物的语义改变(3)泛化⼀个元素以另外⼀个元素的特化,⽽且可以取代更⼀般的元素c.图1234为结构,其中12为静态图,34为实现图56789为⾏为,其中56为交互图,78为⾏为图,9为⽤例图注:各种图见UML概述PPTUML中的4+1视图三、⽤例与⽤例图组成元素:1.参与者,⽤例,表⽰关系的连接线2.参与者与⽤例的关系:⼀根线表⽰3.⽤例之间的关系:包含、扩展、泛化⽤例的建模过程:a.获取原始需求b.识别参与者c.识别⽤例d.识别⽤例之间的关系e.描述脚本f.构建⽤例图g.⽤例描述a.获取原始需求:技巧:实地观察,⽤户指导,原型制作等b.识别参与者:指系统之外,透过系统边界与系统进⾏有意义交互的事物,参与者的确定代表系统边界的确定,就知道哪些外部对象在与系统交互参与者不仅可以由⼈承担,也可以是其他系统,设备,时间等技巧:参与者使⽤功能、改变系统数据、获取系统信息、利⽤系统完成⽇常任务、维护管理系统并保证其资产运⾏、与系统交互、利⽤系统产⽣的结果、或者为时间、⽓温等外部条件参与者的泛化:表⽰⼀个⼀般性参与者(⽗参与者)与⼀个更为特殊的参与者(⼦参与者)之间的联系,⼦参与者继承⽗参与者的⾏为和含义并且增加⾃⼰的特有的⾏为和含义。
苏州大学实验报告院、系计算机学院年级专业12软件工程(嵌入式学术型)姓名潘致远学号1227403088 课程名称Web应用开发成绩用例描述:(1)用例名称:锁住楼层锁用例描述:当电梯出现故障,为保证安全,打开楼层锁,防止电梯停于本层。
参与者:电梯管理员前置条件:电梯出现故障后置条件:无基本操作流:1.找到故障电梯所在位置2.在故障电梯的向下一层和向上一层锁住楼层锁(2)用例名称:按动上下按钮用例描述:当乘客需要上行或者下行时,按动上行或下行按钮。
参与者:乘客前置条件:电梯正常运行后置条件:无基本操作流:1.按动上行按钮可选操作流:按动下行按钮(3)用例名称:按动楼层按钮用例描述:当乘客需要到达某层按钮时,按动某层的按钮参与者:乘客前置条件:电梯正常运行后置条件:无基本操作流:按动某层按钮(4)3.对象图:对类图的实例化,是系统详细状态在某一时刻的快照。
此对象图在如下特定状态:Lock: state=0: 未上锁; floor=1: 1层UpDownLight: state=0: 指示灯关闭GroundFloorLight: floor=1:显示 1层ButtonLight: state=0: 指示灯未亮; floor=1:1层Owtest: isOverweight=false: 电梯未超重QueryList: state=1: 有请求状态FloorButton: state=0: 未有按钮按下; floor=1: 1层的按钮Door: state=1: 门开CloseDoorTimer: autoclosetime=5000: 自动关门的延时为5sBackGroundTimer: autoreturntime=60*1000: 自动到达1层的延时为1minLglifter: state=1: 处于运行中; position=1: 在1层; isOverweight=false: 未超重4.时序图:描述电梯为了完成确定事务,对象之间按照时间消息交互的顺序关系。
UML(UnifiedModelingLanguage统⼀建模语⾔)UML(Unified Modeling Language 统⼀建模语⾔),⼜称标准建模语⾔。
是⽤来对软件密集系统进⾏可视化建模的⼀种语⾔。
UML是⼀种⾯向对象的建模语⾔,它可以实现⼤型复杂系统各种成分描述的可视化、说明并构造系统模型,以及建⽴各种所需的⽂档,是⼀种定义良好、易于表达、功能强⼤且普遍适⽤的建模语⾔。
UML基本内容详述(1)视图 视图是表达系统的某⼀⽅⾯特征的UML建模元素的⼦集;试图并不是图,它是由⼀个或多个图组成的对系统某个⾓度的抽象。
1)⽤例视图(核⼼视图) 强调从⽤户的⾓度看到的或需要的系统功能。
2)逻辑视图 该视图⽤于描述系统内实现的逻辑功能,展现系统的静态或结构组成及特征。
3)组件视图 该视图从系统实现的⾓度来描述模型对象间的关系。
4)配置视图 该视图⽤于说明系统的物理配置。
(2)图表 图表是描述视图内容的图。
1)⽤例图 ⽤于描述外部项与系统提供的使⽤事件之间的联系。
⼀个使⽤事件是系统提供的功能的具体描述,是系统分析⼈员从⽤户⾓度描述系统的功能,是功能与功能之间以及功能与⽤户之间的关系。
使⽤事件定义了系统的功能需求。
简单理解:⽤来描述系统的功能。
2)类图 ⽤于描述系统的静态结构。
类可以⽤不同⽅式连接,主要包括联合、依赖、独⽴和包装。
⼀个系统⼀般有多张类图,⼀个类可在不同的视图中出现。
3)对象图 ⽤于表述系统在某个时刻的静态结构。
对象图也可作为协作图的⼀部分,说明⼀组对象之间的动态协作关系。
对象图与类图的区别:对象图表⽰的是类中的许多对象实例,⽽不是类本⾝。
4)状态图 ⽤于说明类中的对象可能具有的状态,以及由时间引起的状态的改变。
简单理解:描述了系统元素的状态条件和响应。
5)顺序图(时序图) ⽤于描述对象间的动态协作关系。
表达了对象间发⾏消息的时序,同时也表达出对象间的相互作⽤,以及当系统执⾏到某个特定位置时可能会发⽣的事。
使用UML对系统进行建模面向对象的软件工程,同传统的面向过程的软件工程相比,在需求的获取、系统分析、设计和实现方面都有着很大的区别。
UML是OOA和OOD的常用工具。
使用UML来构建软件的面向对象的软件工程的过程,就是一个对系统进行不断精化的建模的过程。
这些模型包括用例模型、分析模型、设计模型,然后,我们需要使用具体的计算机语言来建立系统的实现模型。
当然,在整个软件工程中,我们还需要建立系统的测试模型,以保证软件产品的质量。
使用面向对象的工具来构建系统,就应该使用面向对象的软件工程方法。
然我,我们经常会发现,在实际的开发过程中,很多开发人员虽然能够理解UML的所有图形,却仍然不能得心应手的使用UML来构建整个项目,其很大的原因,是仍然在使用原有的软件工程方法,而不清楚如何使用UML来建立系统的这些模型,不清楚分析和设计的区别,以及他们之间的转化。
应用软件系统,就其本质来说,是使用计算机对现实世界进行的数字化模拟。
应用软件的制造过程,按照UML的方法,就是建立这一些列模型的过程。
本文将就一个图书馆系统,说明如何使用UML来对系统进行这一系列的建模。
关于这个图书馆系统,基本的需求比较简单,就是允许学生可以在图书馆借阅和归还图书,另外,也可以通过网络或者图书馆的终端来查阅和预订书。
当然,图书馆管理员也可以对图书进行管理。
为了简化系统,我们没有把图书馆中的人员作细分。
之所以采用这个相对简单案例,是因为很多人都对图书馆系统有很强的感性认识,这样,读者不需要花很多的时间来理解系统包含的业务知识。
同时,也因为本文只是对使用UML 的过程做一个探讨,着眼于使用UML进行建模的过程,说明各个层次的模型之间的区别和联系,展示系统演进的过程,而不会深入UML的细节方面。
对于更加复杂的系统,其分析和设计的方法是相通的,可以举一反三。
用例模型——系统需求的获取用例模型定义系统做什么,是用来获取系统需求的有效手段。
用例模型由“角色”和“用例”组成。
电梯建模分析与设计问题描述:在一座10层高的宾馆大厅内,有4部由一个控制器控制的电梯。
乘客随时在各层选择要去的楼层。
要求:(1)设计一个电梯算法,满足乘客的要求(侯时应较少)。
(2)区分电梯的状态,如空运行、载入运行、超重、当前有故障等。
(3)在电梯全部无人乘坐时,电梯要按一定条件分布在各层。
(4)保存一个星期内个电梯的运行记录。
问题分析:本问题中可以设计一个电梯控制系统对电梯进行调度,电梯控制系统是一个实时系统,一般来说,实时系统是复杂的,因为它必须处理很多外部并发事件,这些事件的到来次序和几率通常是不可预测的,而且系统必须在事先设定好的时限内做出相应的响应。
1、需求分析1.1 系统描述随着社会的发展,电梯作为一种不可缺少的垂直交通工具,应用越来越广泛,因此有必要开发一个电梯控制系统对电梯进行最优调度。
本电梯系统用来控制4部运行于一个具有10层的宾馆的电梯,每一架电梯都有一个编号,以方便监控与维修。
控制器控制四台电梯,主要负责控制电梯上下,向电梯发送启动、制动、加速、减速、开关电梯门的信号。
若电梯发生故障,还应向相应的电梯负责人发送求救信号。
大楼的每一层都有:(1)两个指示灯:这两个指示灯分别用于指示电梯当前所在的层数和电梯当前的状态(上行、下行或停止)。
(2)按钮:在每一层,都有调用按钮,除了顶层和底层之外,都有两个按钮,一个是向上呼叫按钮,一个是向下呼叫按钮。
在顶层,只有向下呼叫按钮,在底层只有向上呼叫按钮。
(3)电梯锁:用于将本层的电梯门锁住,并使本层的电梯按钮失效,电梯里相应的按钮也失效,使得电梯不能也不可能停在本层。
电梯里面有:(1)标示从“1”到“10”的10个按钮,用于让乘客选择所要到的的层数。
(2)关门按钮:当乘客按下此按钮时,电梯门如果开着将关上,否则不执行任何操作。
(3)开门按钮:当乘客按下此按钮时,电梯如果停止某一层,电梯门将打开,否则不执行任何操作。
(4)超重测试和警报装置:电梯的地面有超重感应装置,当电梯载重达到某一个值时,电梯“超重警报铃”发出超重警报,并且电梯不执行关门操作。
1. 需求陈述
一个无人值守电梯的轿箱通常停放在大楼的第一层.当某楼层有乘客按下按钮,电梯轿箱便会按照指令上升到该楼层接乘客,然后按照乘客的指令升降到指定楼层,到达后的乘客走下电梯。
电梯轿箱停在该楼层,等待下一个乘客的按钮指令。
系统对于等待的时间有一定的限制,在时间限制之内又有乘客按下按钮,电梯则重复前面的动作,电梯轿箱仍按照指令上升或下降到指定楼层,到达后,电梯轿箱继续等待下一个乘客的按钮指令,在每次的等待中,如果等待时间超过限制,电梯轿箱会自动返回到大楼的第一层,在那里继续等待乘客。
2.1 用例图
电梯系统用例图如下,主要包括用例、角色和关系。
用例图
乘客作为电梯里的角色,参与系统的5个用例,呼叫电梯、指定楼层、打开电梯门、关闭电梯门和拨打报警电话。
工作人员参与接受报警的用例。
2.2 类图
类图对系统进行静态建模,静态图主要描述系统功能需求-系统给最终用户提供服务。
类图描述一组类、接口和协作,及他们的关系。
类图
各类的详细声明如下:
(1)B utton类
一个抽象类,电梯停或启动的指示器。
(2)E levator_button
电梯内的人需要到达的楼层。
(3)B uilding_button
处于某楼层的人需要进入电梯上行或下行的指示。
(4)h elp_button
紧急情况下的报警。
(5)c ontrolor
用来控制电梯的上行、下行、关门、开门以及电梯调度工作等。
BState:电梯或楼层按钮的状态,若按下,则给控制器发送一个上行下行命令,否则,控制器控制电梯开门或停止。
3.1建动态模型
●用户A在3楼按上行按钮呼叫电梯,用户希望到7楼去
●上行按钮指示灯亮
●一部电梯到达3楼,电梯内的用户B已按下到9楼的按钮
●上行按钮指示灯熄灭
●电梯开门
●用户A进入电梯
●用户A按下电梯内到7楼的按钮
●7楼按钮指示灯亮
●电梯关门
●电梯到达7楼
●7楼按钮指示灯熄灭
●电梯开门
●用户B走出电梯
●电梯在等待超时到后关门
●电梯载着用户A继续下行到达1楼
3.2异常情况
●用户A在3楼按上行按钮呼叫电梯,用户A希望到1楼去●上行按钮指示灯亮
●一部电梯到达3楼,电梯内的用户B已按下了到9楼的按钮●上行按钮指示灯熄灭
●电梯开门
●用户A进入电梯
●用户A按下电梯内到1楼的按钮
●1楼按钮指示灯亮
●电梯在等待超时后关门
●电梯上行到9楼
●电梯内9楼按钮指示灯熄灭
●电梯开门
●用户B走出电梯
●电梯在等待超时后关门
●电梯载着用户A继续下行到达1楼
3.3状态图
状态图4.1序列图
序列图
4.2协作图
协作图
5. 其它工作及部分代码:
电梯设置
●电梯分为三种状态:静止,上升,下降。
跟随着电梯还有一个数
据,就是电梯当前所在楼层数floor_lift,其中floor_lift<=30&&floor_lift>=1。
●在系统中我们用数组来保存进入电梯的乘客的信息,即目标层数。
●关于超时问题,我们定义时间上限为30分钟。
乘客分析
●乘客的需求分为“上”和“下”两种。
此外乘客还有当前层数
floor_from以及目标层数floor_to。
当然floor_from、floor_to 也是在1~30之间的整数。
初始化
●电梯需要初始化,其中状态为静止state=0,层数floor_lift
设置为1。
目标层数数组需要初始化,即: for(i=0;i<30,i++) ●floor[i]=0;
电梯工作分析
电梯的上升下降
电梯的上升下降设置为一秒一层,即
Switch(state) //state分为0—静止,1—下降,2—上升
{
case 0:
break;
case 1:
floor_lift-=1;
break;
case 2:
floor_lift+=1;
break;
default:
cout<<”error state”<<endl;
}
静止状态检测
当数组全部为0时,将state设置为0.
电梯为静止状态时
用户输入,信息分为direction和floor_from。
Floor_from跟电梯所在楼层floor_lift进行比较,floor_from>floor_lift,那么把电梯状态改为上升,相对的当小于时改为下降。
当floor_from=floor_lift的时候,将乘客的信息加入数组,将乘客目标层数对应的数组元素设置为1。
即floor[floor_to-1]=1。
此时将电梯的状态改为用户的目标方向,即state==direction。
电梯为上升或下降状态时
将用户输入与电梯状态相比:
if((direction==state)&&(floor_lift==floor_from)) //用户目标方向与电梯方向一致时
floor[floor_to-1]=1; //允许用户进入并且输入目标层数
超时设置
当电梯的状态state为0时开始计时
While(i<1800) //每秒检测一次,静止状态保持30分钟则回到一层
{
If(state=!0) //检测状态,一旦状态改变,则停止计时break;
Sleep(1000);
i++;
}
State=1; //设置为下降状态,目标层数改为1楼
floor[0]=1;
6. 设计总结
经过了一个学期的学习和小组成员的共同努力,终于完成了这个作业。
由于我们只是在系统的设计思想上进行了统一的分析,并没有进行系统代码的设计,所以每人负责部分的方法可能名字上有些出入,不影响实际设计。
虽然完成的效果可能不是很好,但是小组的每个成员都很努力了,我们觉得还是有很多收获的。
由于刚刚学习UML这种统一建模语言,对很多概念和问题的理解不是很到位,所以肯定会犯很多错误,希望老师多多指正。
不过,虽然遇到好多不懂的问题,但是小组的每一位成员都能主动地去查阅相关资料了解并在一起讨论,通过这次作业,不仅让我们学到了知识,而且培养了团队协作精
神,我想这也是我们在课堂里面学不到的东西吧。
7.小组成员信息:
姓名学号
李洪岩2012110238 负责序列图及协作图
李东豫2012110021 负责用例分析及类图建模张建华2012111177 负责状态图实现及实验报告。