UML(Unified Modeling Language,统一建模语言)
---------------------------------------------------------UML图:---------------------------------------------------------
原博客:https://blog.csdn.net/chengqiuming/article/details/91129569
---------------------------------------------------------UML四种事物:-------------------------------------------------
构建事务(静态部分,常见的结构事物:类、接口、用例、协作、组件、节点)
行为事物(动态部分包括交互、状态机、活动)
分组事物(UML模型的组织部分)
注释事物(UML模型中的解释部分)
---------------------------------------------------------UML中四种主要的关系:---------------------------------------------------------
关联(描述不同类元的实例之间的连接)
依赖(若一个元素的某些特性随某一个独立元素的特性改变而改变)
泛化(类似于面向对象中的继承关系)
实现(描述规格说明和其实现的元素之间的连接的一种关系)
---------------------------------------------------------------------UML的扩展机制---------------------------------------------------------------------------------
构造型(带书名号)、约束、标记值
-----------------------------------------------------------------E—R图-------------------------------------------------------------
E-R图(Enity Relationship Digram)ERD:数据定义 结构 关系特性
---------------------------------------------------------面向对象软件建模概述:---------------------------------------------------------
面向对象方法的优点:
1.它与人类习惯的思维方法一致。
2.稳定性好。
3.集成了可以复用的思想。
4.开发出的软件,具有良好的可维护性。
面向对象建模技术/对象建模技术(OMT, Object Modelng Technology)
面向对象需求分析(Object-Oriented Analysis, OOA)常用的UML技术:
类图、用例图、交互图(顺序图)、状态图等
面向对象设计(Object-Oriented Design, OOD)
静态模型:类图、对象图、构件图、部署图;
动态模型:交互图(顺序图、通信图)、状态图、活动图;
UML基本构造块:事务、关系、图
------------------------------------------------------用例图(关系+用例+参与者+(边界))---------------------------------------------------------
用例之间的关系:
泛化关系(当多个用例共同拥有一种类似的结构和行为的时候,可以将它们的共性抽象为父用例,其他的用例作为子用例,用例间的这种关系称为用例的泛化关系)
包含关系(当多个用例需要用到同一段行为时,可以把这段共同的行为单独抽象成为一个用例,然后让其他的用例来包含这一用例)
扩展关系
----------------------------------------------------
用例的粒度:指用例包含的系统服务或者功能单元的多少。用例的粒度越大,包含功能越多,反之。
(如果用例数目过多会造成用例模型过大和引入设计困难大大提高。如果用例数目过少会造成用例的粒度太大,不便于进一步的充分析,使用时看情况)
----------------------------------------------------
构建用例模型:用例图:确定系统中所包含的参与者、用例和两者之间的对应关系,用例图描述的是关于系统功能的一个概述。
用例规约:描述用例的细节内容,针对每一个用例都应该有一个用例规约文档与之对应。
----------------------------------------------------
用例图的作用及组成:(消除歧义,达成共识,主要是客户与设计人员)
用例图组成元素:
参与者(系统外部,是直接与系统进行交互的外部实体的抽象。还可以是其他系统,for instance 硬件设备、时钟等)【图标表示法(人),标签表示法(其他玩 意)】
1.位于系统边界之外2.直接且主动的向系统发出动作并获得反馈。
-------------------------
用例(对一组动作序列的描述,系统执行动作序列来为参与者产生一个可观察的结果值,相同的用例在一个系统中只存在一个)【椭圆形表示,内部或者是下方】
用例的确定:
参与者希望系统提供什么功能?
参与者是否会读取、创建、修改、删除、存储系统中的某种信息
参与者是否会将外部的某些事件通知给系统
系统中发生的事件是否通知给参与者
是否存在影响系统的外部事件
用例的特征:
用例必须位于系统边界内部(从外部用户角度出发用户所提供的功能和服务,定义了系统的行为特征)
用例是以动宾短语形式出现的(用例表达是一次完整的人机交互序列,)
用例是相对独立的(在功能上必须是完备的,不能完整实现参与者目的的行为不能称之为用例)
用例的执行结果对参与者来说是可观测且有意义的(用例描述参与者与系统之间的交互行为,而非内在系统活动,用例为业务功能,而非处理过程)
用例是由参与者启动的(用例不应该自动启动,也不应该主动启动另外一个用例,每个用例至少拥有一个参与者)
-------------------------
系统边界
-------------------------
用例图之间的关系:
依赖关系 (包含和扩展):包含关系(Include)是指一个用例可以简单的包含其他用例具有的行为(被包含用例的事件流可以插入其他基础用例的事件流中)【带虚线的箭头,指向被包含的用例】。1.多个用例同时使用到同一段必须行为 2.某一个用例功能过多,事件流过于复杂 参与者不允许直接使用包含用例,如果没有包含用例,基本用例是不完整的 被包含用例可以独立存在 包含用例就是被包含用例
扩展关系(Extend)是指一个用例(扩展用例)扩充了另外一个用例(基础用例)的功能(只有在满足特定条件的情况下才会被执行)【带箭头的虚线,扩展用例指向基础用例】1.用例使用到一段用于增强自身功能的可选行为 没有扩展用例,基础用例也是完整的,可以独立执行。 扩展用例必须依赖基础用例
-----------------------------
泛化关系(编程里面的继承):存在于参与者之间也存在于用例之间(描述了参与者之间特殊与一般的关系,特化用例(子用例)与一般化用例(父用例)之间的关系)【带空心三角箭头实线,指向超类参与者(最基本),子用例指向夫用例】1.多个用例在行为、结构和目的方面存在共性。
-----------------------------
泛化与包含共同点:
从现有的用例的事件流中抽取共有部分,服用现有用例。
泛化与包含区别:
泛化用例是整体相似,子用例启动,父用例不一定被执行。
包含是部分相似,基础用例启动,被包含用例必然执行。
--------------------
关联关系:参与者与用例之间的关系(最重要的关系,消息的传递时双向的)【带箭头的实线,一般来说,从参与者指向用例(如果是设备被使用,是用例指向设备),不带方向的也没问题,指向的是被用的】
----------------------------------------------------------------------------------------------------------------------