⼀．UML简介
UML（统⼀建模语⾔，Unified Modeling Language）是⼀种定义良好、易于表达、功能强⼤且普遍适⽤的可视化建模语⾔。它融⼊了软件⼯程领域的新思想、新⽅法和新技术。它的作⽤域不限于⽀持⾯向对象的分析与设计，还⽀持从需求分析开始的软件开发的全过程。在系统分析阶段，我们⼀般⽤UML来画很多图，主要包括⽤例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况⽽定。其实简单的理解，个⼈理解，UML的作⽤就是⽤很多图从静态和动态⽅⾯来全⾯描述我们将要开发的系统。 ⼆、什么是⽤例
⽤例是对包括变量在内的⼀组动作序列的描述，系统执⾏这些动作，并产⽣传递特定参与者的价值的可观察结果。这是UML对⽤例的正式定义，可能有点难懂。我们可以这样去理解，⽤例是参与者想要系统做的事情。对于⽤例的命名，我们可以给⽤例取⼀个简单、描述性的名称，⼀般为带有动作性的词。⽤例在画图中⽤椭圆来表⽰，椭圆下⾯附上⽤例的名称。
回转窑烧嘴
三、什么是⽤例图
⽤例图（use case diagram）就是由主⾓、⽤例以及它们之间的关系构成的图。该图说明了⽤例模型中的关系。
可以将⽤例图组织到⽤例包中，并归⽤例包所有，让特定包中仅显⽰互为关联关系的内容。
⽤例图由参与者（Actor）、⽤例（Use Case）、系统边界、箭头组成，⽤画图的⽅法来完成。
参与者不是特指⼈，是指系统以外的，在使⽤系统或与系统交互中所扮演的⾓⾊。因此参与者可以是⼈，可以是事物，也可以是时间或其他系统等等。还有⼀点要注意的是，参与者不是指⼈或事物本⾝，⽽是表⽰⼈或事物当时所扮演的⾓⾊。⽐如⼩明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个⾓⾊参与管理，也可以作为借书者向图书馆借书，在这⾥⼩明扮演了两个⾓⾊，是两个不同的参与者。参与者在画图中⽤简笔⼈物画来表⽰，⼈物下⾯附上参与者的名称。
ct二次过电压保护器如何发现⾓⾊：
1. 使⽤系统的主要功能的⼈是谁（即主要⾓⾊）？
2.需要借助于系统完成⽇常⼯作的⼈是谁？欧姆接触
3.谁来维护，管理系统（次要⾓⾊），保证系统正常⼯作？
机组式柔印机
4.系统控制的硬件设备有哪些？
5.系统需要与哪些其他系统交互？其他系统包括计算机系统，也包括该系统将要使⽤的计算机中的其他应⽤软件。其他系统也分成两类，⼀类是启动该系统的系统，另⼀类是该系统要使⽤的系统。
6.对系统产⽣的结果感兴趣的⼈或事是哪些？
智能操作票
⽤例：⽤例代表的是⼀个完整的功能。
如何发现⽤例：
1.⾓⾊需要从系统中获得哪种功能？⾓⾊需要做什么？
锚杆测力计 2.⾓⾊需要读取，产⽣，删除，修改或存储系统中的某种系统吗？
3.系统中发⽣的事件需要通知⾓⾊吗？或者⾓⾊需要通知系统某件事吗？这些事件（功能）能⼲些什么？
4.如果⽤系统的新功能处理⾓⾊的⽇常⼯作是简单化了，还是提⾼了⼯作效率？
5.还有⼀些与当前⾓⾊可能⽆关的问题，也能帮助建模者发现⽤例，例如：
6.系统需要的输⼊/输出是什么信息？这些输⼊/输出信息从哪⼉来到哪⼉去？
7.系统当前的这种实现⽅法要解决的问题是什么（也许⽤⾃动系统代替⼿⼯操作）?
四、UML⽤例图中⽤例之间的关系：
主要⽤来图⽰化系统的主事件流程，它主要⽤来描述客户的需求，即⽤户希望系统具备的完成⼀定功能的动作，通俗地理解⽤例就是软件的功能模块，所以是设计系统分析阶段的起点，设计⼈员根据客户的需求来创建和解释⽤例图，⽤来描述软件应具备哪些功能模块以及这些模块之间的调⽤关系，⽤例图包含了⽤例和参与者，⽤例之间⽤关联来连接以求把系统的整个结构和功能反映给⾮技术⼈员（通常是软件的⽤户），对应的是软件的结构和功能分解。
1）包含关系——include
包含关系：使⽤包含（Inclusion）⽤例来封装⼀组跨越多个⽤例的相似动作（⾏为⽚断），以便多个基（Base）⽤例复⽤。基⽤例控制与包含⽤例的关系，以及被包含⽤例的事件流是否会插⼊到基⽤例的事件流中。基⽤例可以依赖包含⽤例执⾏的结果，但是双⽅都不能访问对⽅的属性。
UML⽤例图关系中包含关系最典型的应⽤就是复⽤，也就是定义中说的情景。但是有时当某⽤例的事件流过于复杂时，为了简化⽤例的描述，我们也可以把某⼀段事件流抽象成为⼀个被包含的⽤例；
相反，⽤例划分太细时，也可以抽象出⼀个基⽤例，来包含这些细颗粒的⽤例。这种情况类似于在过程设计语⾔中，将程序的某⼀段算法封装成⼀个⼦过程，然后再从主程序中调⽤这⼀⼦过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为⼀个⽤例，那添加、删除以及修改都要在⽤例详述中描述，过于复杂；如果分成添加⽤例、修改⽤例和删除⽤例，则划分太细。这时包含关系可以⽤来理清关系。
2）、扩展关系——extend
扩展关系：将基⽤例中⼀段相对独⽴并且可选的动作，UML⽤例图关系中⽤扩展（Extension）⽤例加以封装，再让它从基⽤例中声明的扩展点（ExtensionPoint）上进⾏扩展，从⽽使基⽤例⾏为更简练和⽬标更集中。扩展⽤例为基⽤例添加新的⾏为。扩展⽤例可以访问基⽤例的属性，因此它能根据基⽤例中扩展点的当前状态来判断是否执⾏⾃⼰。但是扩展⽤例对基⽤例不可见。
对于⼀个扩展⽤例，可以在基⽤例上有⼏个扩展点。
例如，系统中允许⽤户对查询的结果进⾏导出、打印。对于查询⽽⾔，能不能导出、打印查询都是⼀样的，导出、打印是不可见的。导⼊、打印和查询相对独⽴，⽽且为查询添加了新⾏为。因此可以采⽤扩展关系来描述：
在以下⼏种情况下，可使⽤扩展⽤例：
2.1）.表明⽤例的某⼀部分是可选的系统⾏为（这样，您就可以将模型中的可选⾏为和必选⾏为分开）；
2.2）.表明只在特定条件（如例外条件）下才执⾏的分⽀流；
2.3）.表明可能有⼀组⾏为段，其中的⼀个或多个段可以在基本⽤例中的扩展点处插⼊。所插⼊的⾏为段和插⼊的顺序取决于在执⾏基本⽤例时与主⾓进⾏的交互。
3）、泛化关系——generalization
泛化关系：⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。⽗⽤例通常是抽象的。UML⽤例图关系中泛化关系在实际应⽤中很少使⽤，⼦⽤例中的特殊⾏为都可以作为⽗⽤例中的备选流存在。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议