UML学习心得体会.docx
- 文档编号:10669389
- 上传时间:2023-05-27
- 格式:DOCX
- 页数:17
- 大小:31.21KB
UML学习心得体会.docx
《UML学习心得体会.docx》由会员分享,可在线阅读,更多相关《UML学习心得体会.docx(17页珍藏版)》请在冰点文库上搜索。
UML学习心得体会
——uml学习体会
养成良好的绘制uml序列图的习惯
在学习uml的过程中,你可能会遇到绘制uml序列图的问题,这里就讨论一下怎样才能养成良好的绘制uml序列图的习惯。
有一些方法可以帮助您提高uml序列图的质量和效力。
它们包括:
和主题问题专家一起验证决策;使解决方案尽量简单;为绘制消息和返回值选择一种一
致且有效的风格;将序列图分层;遵循一致的逻辑风格;牢记序列图是动态的。
一:
验证决策
绘制uml序列图时,我做了一些对其它模型可能有潜在影响的决策。
例如,在对第10步建模时,假设〔大致上是个设计决策〕费用显示屏幕同时也处理学生对费用是否可接受所进行的验证。
该决策应该由用户界面原型反映出来,并由主题问题专家(sme)进行验证。
您应该和sme〔特别是那些对于如何开发类似模型有着深刻见解的富有经验的人〕一起执行序列图的绘制工作。
二:
保持简单
在对第2和第3步建模时,我突然意识到学生可能应该使用口令进入系统。
在向sme提出了这个概念后觉察我错了:
姓名和学号组合对于我们的目的来说已经足够唯一,并且学校也不希望增加复杂的口令管理。
这是个很有意思的决策,因为这是学校的一个运作策略,所以可以作为一条商业规那么记载到增补标准中。
通过与sme一起检验这个想法,而不是假定我比他们知道得更多,我防止了“镀金〞的时机,因而减少了我们小组开发这一系统所需的工作。
三:
绘制消息和返回值
绘制uml序列图时我更喜欢从左至右地绘制消息,从右至左地绘制返回值,尽管这样对于复杂的对象/类来说不总是非常适宜。
我将消息上的标签和返回值对齐到离箭头最近的位置。
我不喜欢在序列图上标出返回值,为的是使图尽可能地简化。
不过,始终标出返回值也同样有效,特别是在序列图用于设计而不是分析目的时。
〔我希望我的分析图尽量简单,而设计图尽量全面。
〕在分析期间,我的目标是理解逻辑和确保逻辑的正确性。
而在设计期间,那么要赋予消息精确的细节。
四:
将序列图分层
绘制uml序列图时我喜欢将序列图从左至右地分层。
先标出参与者,然后是控制器类,然后是用户界面类,最后是商业类。
在设计期间,可能需要添加系统类和持久类,我通常将它们放在序列图的最右侧。
以这种方式将序列图分层往往使它们更易于阅读,并且更容易找出分层逻辑问题,例如用户界面类直接访问持久类。
五:
遵循一致的逻辑风格
请注意,在图1序列图所示的过程中,逻辑风格做了局部更改。
一开始,特别是在登录时,用户界面处理一些根本逻辑--而在选择研习班,以及稍后的验证时,那么是控制器类进行处理。
这实际上是个设计问题。
我不会在这个问题上纠缠太久,但和往常一样,我建议选择一种适合于您的建模风格,然后始终如一地贯彻在所有序列图中。
六:
牢记序列图是动态的
绘制uml序列图时您可能听说过诸如动态建模和静态建模这样的术语,其他一些熟悉面向对象建模技术的开发人员常常会提到它们。
您甚至可能听到过有关每种风格的优点的争论。
动态建模技术主要集中在标识系统中的行为,包括序列图的绘制和活动图的绘制〔请参阅“如何绘制uml活动图〞〕以及uml协作图的绘制。
而静态建模那么集中在系统的静态方面,包括类、它们的属性,以及类之间的关联。
类模型和持久/数据模型一样,都是静态建模的主要产物。
uml学习心得
(一)uml〔unifiedmodelinglanguage,统一建模语言〕是一组用于描述ooad过程的图形化表达方式。
uml为交流面向对象的设计中的需求,行为、体系结构的实现提供了一套综合的表示法。
(二)uml由9个不同类型的图组成:
用例图:
显示了系统的外部可视行为。
用例图描述了系统外的人员和系统的交互动作,以及系统的响应,该类型的图可以用于描述系统的功能需求。
活动图:
显示系统行为的峡谷纳西描述。
活动图描述了单个功能需求内部的细节行为,包括根本的场景和一些可选的场景。
组件图:
显示了系统的体系结构。
组件图描述了系统的可部署单元〔可执行文件,组件,数据存储和其他一些内容〕以及一些借口,可部署单元通过这些接口进行交互,该图可以用于研究系统的体系结构。
顺序图:
显示了对象随着时间的交互。
顺序图描述了某个功能需求的路径或场景内相对时间的详细行为,该图可用于理解系统元素之间的消息流程。
协作图:
显示了对象的交互,强调对象之间的关系。
〔在里面找不到了〕
类图:
显示了类的定义和关系。
类图描述了系统设计中的类和接口,以及他们之间的关系。
该图可用于定义内部的,面向对象的代码结构。
状态图:
显示了响应时间的状态改变。
状态图描述了系统如何改变状态以相应内部的和外部的事件,确保每个事件都被适当的处理。
部署图:
显示了系统的物理体系结构。
部署图描述了系统的可部署单元〔应用,组件,数据存储等〕如何被赋予不同的节点,这些节点如何交互通信,用于系统映射和负载的研究。
包图:
显示了设计的层次结构。
包图描述了设计的相关元素如何按组结合在一起,以及他们之间的关系。
(三)各种图的作用
1.用例图〔usecasediagram〕
它是uml中最简单也是最复杂的一种图。
说它简单是因为它采用了面向对象的思想,又是基于用户视角的,绘制非常容易,简单的图形表示让人一看就懂。
说它复杂是因为用例图往往不容易控制,要么过于复杂,要么过于简单。
用例图表示了角色和用例以及它们之间的关系。
2.类图〔classdiagram〕
uml面向对象中是最常用的一种图,类图可以帮助我们更直观的了解一个系统的体系结构。
通过关系和类表示的类图,可以图形化的方式描述一个系统的设计局部。
3.对象图
uml面向对象中对象图是类图的实例,几乎使用与类图完全相同的标识。
它们的不同点在于对象图显示类的多个对象实例,而不是实例的类。
一个对象图是类图的一个实例。
由于对象存在生命周期,因此对象图只能在系统某一时间段存在。
4.状态图
描述一个实体基于事件反响的动态行为,显示了该实体如何根据当前所处的状态对不同的时间做出反响的。
通常创立一个uml状态图是为了以下的研究目的:
研究类、角色、子系统、或组件的复杂行为。
5.时序图
又称顺序图,描述了对象之间动态的交互关系,着重表达对象间消息传递的时间顺序。
顺序图由一组对象构成,每个对象分别带有一条竖线,称作对象的生命线,它代表时间轴,时间沿竖线向下延伸。
uml面向对象中顺序图描述了这些对象随着时间的推移相互之间交换消息的过程。
消息用从一务垂直的对象生命线指向另一个对象的生命线的水平箭头表示。
图中还可以根据需要增加有关时间的说明和其他注释。
6.协作图
uml面向对象中协作图用于显示组件及其交互关系的空间组织结构,它并不侧重于交互的顺序。
协作图显示了交互中各个对象之间的组织交互关系以及对象彼此之间的链接。
与序列图不同,协作图显示的是对象之间的关系。
另一方面,协作图没有将时间作为一个单独的维度,因此序列号就决定了消息及并发线程的顺序。
协作图是一个介于符号图和序列图之间的交叉产物,它用带有编号的箭头来描述特定的方案,以显示在整个方案过程中消息的移动情况。
协作图用途:
通过描绘对象之间消息的移动情况来反映具体的方案。
显示对象及其交互关系的空间组织结构,而非交互的顺序。
7.活动图〔activitydiagram〕
uml面向对象中uml活动图记录了单个操作或方法的逻辑,单个用户案例,或者单个业务流程的逻辑。
描述系统中各种活动的执行顺序,通常用于描述一个操作中所要进行的各项活动的执行流程。
同时,它也常被用来描述一个用例的处理流程,或者某种交互流程。
活动图由一些活动组成,图中同时包括了对这些活动的说明。
当一个活动执行完毕之后,控制将沿着控制转移箭头转向下一个活动。
活动图中还可以方便地描述控制转移的条件以及并行执行等要求。
组件图是用来反映代码的物理结构。
从组件图中,可以了解各软件组件〔如源代码文件或动态链接库〕之间的编译器和运行时依赖关系。
使用组件图可以将系统划分为内聚组件并显示代码自身的结构。
组件图的主要目的是显示系统组件间的结构关系。
9.配置图
uml面向对象中配置图描述系统中硬件和软件的物理配置情况和系统体系结构。
在配置图中,用结点表示实际的物理设备,如计算机和各种外部设备等,并根据它们之间的连接关系,将相应的结点连接起来,并说明其连接方式。
在结点里面,说明分配给该结点上运行的可执行构件或对象,从而说明哪些软件单元被分配在哪些结点上运行。
uml是一种软件建模语言,可以对任何具有静态结构和动态行为的系统进行建模。
在关注它建模特性的同时更要关注它的过程特性--在什么时间做什么工作,用什么模型,让哪些人来做。
对系统用户而言,软件的开发模型向他们描述了软件开发者对软件系统需求的
理解。
让系统用户查看软件对象模型并且找到其中的问题,可以使开发者不至于从一开始就发生错误。
对软件开发而言,软件的对象模型有助于他们对软件的需求以及系统的架构和功能进行沟通。
对软件的维护和技术支持者而言,在软件系统开始运行后的相当长的一段时间内,软件的对象模型能够帮助他们理解程序的架构和功能,迅速地对软件所出现的问题进行修复。
建模并不是仅对大型的软件系统,甚至一个小型的留言本也能从建模的过程中受益。
利用uml可以有效地解决软件设计和分析过程中的沟通和交流问题,可以高效的了解整个系统结构,并且在设计之初就将软件的设计结构和思想固化在纸上有利于躲避工程实施过程中程序员离开的风险。
uml可以贯穿软件开发周期中的没一个阶段,在开发阶段,他可以用于说明、可视化、构建和书写面向对象软件制品的设计语言。
uml能贯穿整个软件开发过程是因为在每个阶段都能够提供相应相应的图形来对应,使得改变需求,设计代码,测试分析能变得相对简单。
在需求分析过程中,应该分为两个过程:
1需求的获取2、需求的分析。
需求的获取,往往不受到重视,在网上经常看到有人说,特别是国内目前的情况,工程工期紧,公司往往想方设法先把工程拿下来,然后就拿自己公司以往做过的工程做蓝本,然后再根据顾客的需求改动,再次开发,测试,交付就完工了。
但如果需求的获取,做不好,往往对后面的步骤流程造成很大的影响,造成太多的改动和损失。
所以为了得到更好的需求,使用uml建模能变得相对简单。
例如需求的用例图对系统的功能模型的搭建。
用例间的关系有包含、扩展、泛化三类。
用例图包括角色、用例和关系。
角色可以有角色的描述,用例可以有用例的描述,这些描述在交流或评审中会非常有用。
用例可以泛化,泛化用例具有根本用例的功能,还可以做得更多。
角色也可以泛化,泛化角色能执行原角色能执行的所有用例,还可以执行更多的用例。
除了根本用例,角色不能与包含用例、扩展用例和泛化用例有联系。
一个用例可以对应一个类图。
增、删、改、查一般来说对于大多数应用做为一个简单的操作即可,不必要作为一个用例来分析。
篇三:
uml实训总结
实训总结〔收获与体会〕
通过一个学期的uml学习,我从书本上获取了根本的理论知识,而真正的学以致用,将书本理论知识运用到实际的过程,是这次uml实训的表达。
三个周的uml实训,主要是围绕着一个实训题目“基于uml系统需求分析与设计--合倍利业务流管理系统〞进行的,以小组为单位进行文档的编写,其中还对各种流程图、类图、用例图等的绘制,整个过程设计了知识的方方面面。
从中让我认识到uml的作用和运作模式以及方法,它是一种统一建模的标准语言,现在对于大多数软件开发来说,都使用uml作为建模语言,形成了统一的标准。
它是图形化的的语言,可以很直观的描述一个事物的状态、行为与特征,很好的说明与表达了“合贝利任务管理〞这个系统。
总之,在我看来,uml是一种定义良好、易于表达、功能强大且普遍适用建模语言。
融入软件工程领域的心思想、新方法和新技术,作用域不限于支持面向对象的分析和设计,也不单纯是一种方法,仅仅是一组符号而已,它可以对任何具有静态机构和动态行为的系统进行建模,所以我很喜欢适用uml,在今后的学习中,我还会进一步对该模型的学习,因为它方便、简洁、干净、清爽,直观形象,把整个软件系统的开发流程都融入进去。
这次实训过程中,文档方面的编写,遇到了很多的问题,这些问题主要是对根底知识的理解和把握不够,不能融会贯穿和学以致用,有时遇到困难的时候真的不知如何着手解决,但是,我始终相信的那句话“读万卷书,不如行万里路,行万里路不如名师指路〞。
所以,当遇到自己模糊和自己难以解决的问题时,向指导老师和懂的同学请教,帮助解决我遇到的问题,经过他们的讲解后,我下来自己在分析,在动手,从不理解到理解,从不会到会,从懂到懂,这是一个让我学习愉快的过程,在这个过程中,既可以丰富了自己的知识,还可以和老师和同学进行有效地方沟通。
在这次实训过程中,感触最深的也就是合作精神了。
独木难成林,单枪匹马,那是最错误的思想和做法。
这次我是深有感触了。
对于一个系统的分析,到最终工程的完成,需要分析每个文档,然后在写出纸质的文档,而在每个文档中,内容比拟多,分析也要求比拟到位,所以单独凭借一个人去完成,似乎有点困难,
于是我们小组,将每个文档进行分析,能独立成块就分配给每一个人,这样,每个人都有自己的任务,谁也不会闲着,既学到了知识,也充实了自己。
另外一点,就是我深深体会到了积累知识的重要性。
在实训当中我们遇到了不少难题,但是经过我们大家的讨论和老师细心的一一指导,问题得到了解决。
两个月的实训结束了,收获颇丰,同时也更深刻的认识到要做一个合格的程序员并非我以前想像的那么容易,最重要的还是细致严谨。
社会是不会要一个一无是处的人的,所以我们要更多更快地从一个学生向工作者转变,总的来说我对这次实习还是比拟满意的,它使我学到了很多东西,为我以后的学习做了引导,点明了方向。
实训的日子即将结束,回想这一个过程,有过痛苦,有过烦恼,有过喜悦和有过成功。
痛苦烦恼的是自己对所学书本知识掌握得不是很扎实,面对着从书本上学到的知识与实际联系不起来,总结起来就是自己的动手练习的时间太少。
而喜悦的是,在做的过程中遇到了困难和问题,主动向老师和会的同学请教,然后再做,直至做正确做成功后的那种喜悦。
团队的力量是无穷的,通过组员的共同努力,完成了实训工程。
虽然,我们这组的工程存在着诸多的缺乏和缺点,但这正是以后学习和工作需要弥补的。
这次实训将为我以后进入社会提过了一笔珍贵的财富,是对我能力的一个见证。
最后,不得不感谢指导教师熊飞老师的辛勤指导,和小组成员的共同努力!
篇四:
uml课设心得
六月23号至六月27号,是我们班进行uml专用周课程设计的时间,虽然时间并不是很长,只有短短的一个星期而已,但是让我受益匪浅,通过这次的uml课程设计,使我所学的书本知识得到了全面的检验,也让我对这门课程有了更加深厚的体会。
这次课程设计我们没有另外选题,而是在我们之前做过的系统之上加以完善和改良。
现在看看之前提交的作品,确实不近人意;但经过在网上的不断查找资料,终于还是将它完成。
之前我做的系统状态图和活动图,为了锻炼自己这次选择了交互图〔也就是时序图和协作图〕。
虽然说自己没有这方面的经验,也不是特别熟悉其工作流程,但是有了在网上查找资料得来的一些根底和课本里的讲解,自己对它也有了一定初步的认识,虽然不是很全面,但还是跌跌撞撞的完成。
其中还因为和组员没有沟通好导致用的类不同,费了好大劲才改回来。
最后,这次课设使我们发现考试真的并不是最重要,最重要的是能运用所学的知识。
在整个uml课程的学习过程中,我们突破了传统学习模式,把被动接受转变为主动学习。
不再是用学到的知识解题,而是在实际运用时遇到什么学什么,重在把知识应用于实际。
立体的运用比死板的模仿更有效也更容易接受。
下学期就大四了,也就是大学校园里的最后一年,而课设里学到的动手能力和分析问题解决问题的能力也将是我们毕业找工作的一大筹码。
篇五:
uml学习重点汇总
第一章oom&软件建模概述uml〔unifiedmodelinglanguage〕
通用的标准建模语言,可以对任何具有静态结构和动态行为的系统进行建模。
标准建模语言uml适用于以面向对象技术来描述任何类型的系统,而且适用于系统开发的不同阶段,从需求规格描述直至系统完成后的测试和维护。
特点:
统一标准,面向对象,可视化、表达能力强,独立于过程,uml很适合于以体系结构中心的、用例驱动的、迭代式和渐增式的软件开发过程第二章uml构成1.uml的“4+1视图〞
从某个角度观察系统构成系统的一个视图,每个
数据库
5活动图——泳道图
泳道将活动图中的活动化分为假设干组,并把每一视图都是系统描述的一个投影,说明了系统某个侧面的特征。
〔1〕用例视图〔2〕逻辑视图〔3〕组件视图〔4〕进程视图〔并发视图〕〔5〕配置视图〔部署视图〕2.uml的模型图:
模型图是一组uml模型元素构成的有向图表示,它通常由一组节点〔uml根本模型元素〕,及节点之间的连线〔关系〕组成。
(1)用例视图:
用例图
(2)静态模型:
类图、对象图、包图、构件图和配置图(3)动态模型:
活动图、顺序图、状态图和协作图3.用例图.
用例图是表达用例和参与者及其关系的载体。
关系包括:
关联关系,依赖关系
实现关系:
3.用例图(续)——用例之间关系1〔包含与扩展〕.3.用例图(续)——用例之间关系2〔泛化〕.3.用例图(续)——用例与参与者
用例usecase:
一组用例的实例〔场景〕,其中每个实例都是系统执行的一系列活动,这些活动产生了对每个参与者而言可观察的返回值。
描述了从参与者角度看系统做了什么用例模型本身不是面向对象建模技术。
参与者actor:
是指在系统外部与系统交互的人或其他系统,以某种方式参与了系统内用例的执行。
4.交互式视图图(顺序图、协作图)
1〕协作图:
采用图的形式展示对象间的交互
2〕顺序图:
采用栅栏格式展示对象间的交互
顺序图与协作图的优缺点:
顺序图
〔优点〕强调消息的时间顺序及对象生命线〔优点〕大量详细表示法选项
〔缺点〕强制在右侧增加新对象,消耗空间大协作图
〔优点〕强调结构组织,复杂交互表达更容易〔优点〕空间利用率高,和方便添加新对象〔缺点〕不宜查询消息的顺序,表示法选项少5活动图
活动图用于表示完成一个操作所需要的活动,或者是一个用例实例〔场景〕的活动。
活动图适合描述动作流和并发处理行为。
5活动图——实例
组指定给负责这组活动的业务组织即对象。
泳道区分了负责活动的对象,明确地表示了哪些活动是由哪些对象进行的。
每个活动只能明确地属于一个泳道。
8.状态图〔状态机〕
状态图(statediagram)一个对象在其生存期间的动态行为,表现对象响应事件所经历的状态序列以及伴随的动作。
并不是所有类都有相应的状态图。
状态图只适用于:
具有假设干个确定状态,类的行为在这些状态下
会受到影响且被不同的状态改变。
状态图与活动图的区别与联系〔1〕相同的图形符号。
〔2〕描述一个系统或对象在生存周期的状态或行为。
〔3〕描述系统或对象在多进程中同步或异步操作并发行为。
〔4〕用条件分支来描述系统或对象的行为控制流。
联系:
〔2〕描述多个对象共同完成一个操作的机制不同。
活动图置于责任区〔泳道〕中,责任区将活动按责任目标和组织归属的原那么分类。
状态图采用状态嵌套方式描述多
对象协作。
7、类图
类图表示系统中类及类和类之间的关系,用于对系统的静态结构进行描述。
类用来表示系统中需要处理
的事物.类的关系:
〔1〕关联:
关联表示两个类的对象之间存在某种语义上的联系。
〔2〕聚集:
聚集也称为聚合,关联的特例聚集表示类与类之间的关系是整体与局部的关系。
〔3〕泛化:
uml中的泛化关系就是通常所说的继承关系,它是通用元素和具体元素之间的一种分类关系。
〔4〕依赖和细化。
2)类的关系——关联
间具有细化关系。
细化用来协调不同阶段模型之间的关系。
构件图由构件、接口及构件之间的关系组成。
构件图主要用于系统的静态实现视图模型,通过构件的依赖关系描述系统软件的组织结构,展示系统不同物理构件及其关系。
系统业务模型:
业务过程和文档。
系统开发管理模型:
开发期间产物及关系系统实现模型:
系统实现的构件建模
第六章从需求到设计包图〔packagediagram〕
概念性的模型管理工具,用于将大型的软件系统中大量的建模元素有序的组织起来。
运用包可以把语义上相近的可能一起变更的模型元素组织在同一个包中,对包中的元素作为一个整体对待,并
2)类的关系——聚集
聚集也称为聚合,是关联的特例。
聚集表示类与类之间的关系是整体与局部的关系。
〔1.共享聚集聚合:
聚集关系中处于局部方的对象可同时参与多个处于整体方对象的构成.
〔2.组合聚集.组合:
局部类完全隶属于整体类.局部与整体共存.整体不存在局部也随之消失。
2)类的关系——泛化
uml中的泛化关系就是通常所说的继承关系〔或一般与特殊关系〕。
2)类的关系——依赖
两个类之间有依赖,说明其中一个类.客户类.依赖于另一个类〔供给类〕所提供的某些效劳。
2)类的关系——细化
当对同一个事物在不同抽象层次上描述时,这些描述之
系统物理配置模型:
数据文件、日志、安装/卸载等文件且控制它们的可视性和存取。
包拥有内容,包括类、接构件建模口、组件、节点、协同。
usecase、图,甚至其它包。
集成系统模型:
对api建模,帮助利用已有组件。
第三章unifiedprocess
(1)构件:
系统中遵从并实现一组接口的物理的、可替换up的构成:
二维的面向对象开发模型,兼顾技术和管理。
的软件模块。
构件是软件复用的根本物理实现单元,是工作流:
过程工作流(业务建模+需求+分析与设计+实施+逻辑元素模型〔类、接口、协同等〕的物理包
测试+部署)和3个支持工作流〔配置和变更管理+工程管理+环境〕
4个阶段:
初始+细化+构造+交付
up的迭代策略。
up的迭代开发策略:
以体系结构为中心,以质量管理和
风险控制为目标,以用例为驱动,采用迭代式以螺旋上
升的模式进行软件开发。
(2)构件的接口:
一个构件可以定义对其他构件可见的接第四章初始阶段(inception)口。
构件间依赖通过指向所使用的构件接口来表示。
接1.初始阶段的目标和任务:
口描述一个构件能提供效劳的操作,是一个有操作而无做适当的调研,以形成对新系统的整体目的和可实现的类。
包括输入和输出接口。
行性形成一个合理的意见。
建立工程的软件范围和边界条件,包括一个操作“前景〞,
“接受准那么〞和产品中包含什么,不包含什么…确定核心的用例,这是系统运行的主要场景,它将决定系统设计的方案
针对主要的场景,确定或者演示至少一个备选的系统结9部署图〔deploymentdiagram〕
构
由节点和节点之间的联系组成,描述了处理器、设备和对整个工程估计总本钱和方案(更详细的估计将安排在软件构件运行时的体系结构。
细化阶段中)
估计可能的风险(不可预计性的来源〕为工程准备支持环境2.初始阶段的制品:
用例模型+用例描述,词汇表,补充性规格说明,前景,
业务规那么9部署图——结点
9.用例描述
节点是存在于运行时的代表计算资源的物理元素,可摘要:
简介描述用例,通常只给出主成功场景。
以代表一种物理硬件设备或软件元素。
非正式:
用假设干非正式段落来描述用例,通常给出多个包含:
处理器和设备两种类型不同场景。
详述:
详细描述用例,通常给出所有的步骤及场景,并10部署图——结点间联系
给出前置和后置条件等细节节点间通过物理连接发生联系,以从硬件方面保证注意:
用例描述的方法系统各节点之间的协同运行。
包括通讯关联、依赖联系4.用例的获取过程
等。
(1)选择系统边界
(2)寻找参与者(3)确定每个参与者的目标(4)定义用例5.用例的定义:
一般为每一个用户目标定义用例
确定用例
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- UML 学习心得 体会