`
0428loveyu
  • 浏览: 30884 次
  • 性别: Icon_minigender_2
  • 来自: 西安
文章分类
社区版块
存档分类
最新评论

《UML那些事儿》 - 书摘精要

 
阅读更多
(P2)
UML是一种获取了国际双标准的图形语言,专门用来表达 OOAD (Object-Oriented Analysis and Design) 的生成;

UML深具面向对象 (Object-Oriented) 色彩;

(P3) 从分析设计来看,不同阶段的 UML 模型会呈现出不同的抽象程度;

(P5)
各行各业中的“老鸟”都积累了许多经验法则,所以如果想迅速脱离“菜鸟”身份,最好偷学几招有用的经验法则;

一个好的、成熟的开发方法可以积累许多有用的经验法则,不仅可以降低学习曲线,也可以提高生成的品质;

目前,最蓬勃发展的经验法则就是模式(Pattern)。每一个模式用来解决一个特定的问题,所以它是一个很好的经验法则,多学有益;

(P12) RUP - Rational Unified Process

(P15) 在OO的世界中,对象是最小的单元,数据和行为都被封装在里面,彼此之间必须通过传递信息来沟通合作;

(P17)
六类UNL图:类图、对象图、包图、活动图、序列图、用例图;

(P18)
类图 —— 采用三格的矩形图示,顶格放置类名称,中格放置属性名称,底格放置操作名称。可以将类的属性格或操作格隐藏起来,节省空间;

(P19)
减号(-)为私有可见性;
加号(+)为公开可见性;
井号(#)为保护可见性;
否定号(~)为“包”内可见;

(P20)
关联:
1. 图示为实线;
2. 多元关联的图示是连接大菱形的实线;
3. 在 UML 2 中,关联的箭头端代表具有导航性。打个小叉就是不可导航;单纯直线代表还未指定可导航或不可导航;

(P22)
聚合 (Aggregation) 和 组合 (Composition)
聚合与组合都具有“整体-部分”的特性,唯一的差别在于可否分享 (Share);
聚合关系中的部件 (Part Object) 可以与其他整体 (Whole Object) 分享,但是组合关系中的部件则由整体独立拥有;

聚合端为空心小菱形;
组合端为实心小菱形;

(P23)
泛化 —— 泛化将类分为较为泛化的类和较为特化的类;

(P24) 泛化的图示为带有大三角形箭头的实践,由特化的子类连接指向泛化的超类;

(P24) 依赖 —— 依赖的图示是带箭头的虚线,由依赖元素指向供应者元素;

(P24) 接口 —— 供给接口、需求接口;

(P25) 注释 (Comment) —— 注释的图示是右上角有折角的矩形,通过虚线连接被注释的元素;

(P26) 对象图 ——
对象和类共用矩形图示,不过对象名称下方有底线,类名称下方没有底线;
对象名称经常被省略,所以常见带有冒号的类名称,这其实是个缺名的对象;

(P26) 两个对象之间的关系称为链接(Link);

(P27) 包图 —— 包的图示是上小下大的两个重叠矩形,可以将元素放置其内,也可以将包的内容隐藏起来;

(P29) 活动图 ——
1. 控制流;
2. 对象流;
3. 起点;
4. 活动终点、流终点;

(P34)
序列图 —— 序列图用来表达系统内部一群对象的交互情况:
1. 生命线:顶端连接矩形的虚线;
2. 执行发生:长条矩形;
3. 消息:一条带箭头的线段,横跨在两个生命线上;
4. 终止:表达生命线终止的时刻。终止的图示是一个大叉,放置在生命线的虚线底部,代表生命线已经终止;

(P39)
用例图 —— 用例图用来表达系统对外提供的服务或功能,适合用来作为需求搜集阶段的工作;

用例 —— 采用椭圆图示,名称可放在椭圆内部或底部;

执行者 —— 采用人形图示;

包含关系: <<include>> 基用例 --> 被包含用例;
扩展关系: <<extend>> 扩展用例 --> 基用例;

--- 3.1 根基 ---

(P44) 元素 Element —— 元素是模型的成分,它可以拥有自己的元素。元素是抽象元素,不能直接诞生实例;

(P45) 元素有一条组合关系 (Composite Aggregatio) 连接自己,意味着元素子类所诞生的实例之间具备拥有对方的能力;

(P47) 关系 Relationship —— 关系是一个抽象的概念,它指定元素之间的某种关系;关系直接继承元素,是元素的子类;

(P49) 有向关系 Directed Relationship —— 有向关系代表源模型元素集合和目标模型元素集合之间的关系;

(P50) 关联 (Association) 本身就直接继承关系,未继承有向关系,这意味着关联不具有方向性;

(P51) 注释 (Comment) —— 注释是一个文本注解,可以附加在元素集上;

(P53) 一个元素可以拥有多个注释,而且一个注释只能被一个元素所拥有,或者不被任何元素所拥有。因为两者之间是组合关系,所以一旦元素被销毁了,注释也会跟着被销毁;

(P54) 元素与注释之间附加或拥有的导航性 (Navigation)。当注释附加于某一元素上时,该元素不知道注释的存在,因为单向关联仅能由注释端导航到元素端。至于拥有则恰好相反,元素知道其拥有的注释,但是注释不知道元素的存在,因为恰好是单向组合,仅能由元素端导航到注释端;

--- 3.2 名称空间 ---

(P54) 具名元素 (Named Element) —— 具名元素是模型里可以具有名称的元素;任何一个缺名 (A Absence of a Name) 的具名元素都还是唯一的元素,只不过它们刚好缺少名称而已;

(P56) 名称空间 (Namespace) —— 名称空间是模型中的一个元素,它包含可以由名称识别的具名元素的集合;名称空间与被拥有成员之间为组合关系,意味着名称空间拥有这些成员,一旦名称空间被永久删除了,它的被拥有成员也会一并被永久删除;

(P57) 包 (Package) 也是一种常见的名称空间;

(P58) 可见性种类 (Visibility Kind) —— 可见性种类是一个枚举类型,它定义决定模型中元素可见性的文字;

(P60) 装包元素 (Packageable Element) —— 装包元素指可以被一个包直接拥有的具名元素;原先具名元素的可见性可设可不设,但是只要是装包元素,就一定要设置可见性;

(P63) 元素导入 (Element Import) —— 元素导入标示另一个包中的元素,并允许使用名称来引用,不需要限定符;

(P66) 包导入 (Package Import) —— 包导入是一种关系,允许使用非限定名称从其他名称空间引用包成员;

--- 3.3 多重性 ---

(P70) 多重性元素 —— 多重性定义一个包含间隔,间隔开始于一个下限,终结于一个上限 (可能是无限)。多重性元素嵌入这个信息,为元素的实例化指定允许的候选;

(P72)
类型 (Type) —— 类型约束了类型元素表达的值;

类型元素 (Typed Element) —— 类型元素拥有一个类型;

--- 3.4 表达式 ---

(P74)
值规格 (Value Specification) —— 值规模是包含对象和数据值的实例集合(可能为空)的规格;

表达式 (Expression) —— 表达式是一棵结构化的符号树,在上下文中计算时,它表示值的集合(可能为空);

(P75) 不透明表达式 —— 不透明表达式未经解释的文本陈述,在上下文中计算时,它表示值的集合(可能为空);

--- 3.5 约束 ---

(P77) 约束 (Constraint) —— 约束是为了声明元素的某些语义,用自然语言文本或机器可读语言表达式的条件或限制;

--- 4.1 实例 ---

(P82) 实例规格 (Instance Specification) —— 实例规格是表达被建模系统中的实例的建模元素;

(P85) 槽 (Slot) —— 槽说明由实例规格建模的实体对具体的结构性由一个值或一些值;

--- 4.2 类元 ---

(P87) 类元 (Classifier) —— 类元是实例的分类,它描述拥有共同特征的实例集合;UML采用斜体字来标示抽象类的名称,不同于一般类的正体字;

(P89) 泛化 (Generalization) —— 泛化是一个较普通类元和一个较特殊类元之间的分类关系。特殊类元的每个实例也是普通类元的非直接实例。这样,特殊类元继承了更普通类元的特征;

(P92) 可重定义元素 (Redefinable Element) —— 可重定义元素是在类元的上下文内定义的元素,在另一个特化(直接或间接)该上下文类元的上下文中,它可以重定义为更特殊或不同;

--- 4.3 特征 ---

(P96) 定义 (Feature) —— 特征声明类元实例的行为或结构特征;类元特征的名称有底线,一般实例特征的名称是没有底线的;

(P98) 结构特征 (Structure Feature) —— 结构特征是类元的一种类型化特征,它指定类元素实例的结构;

(P99) 行为特征 (Behavioral Feature) —— 行为特征是类元的一种特征,它指定类元实例的行为方面;

(P99) 参数 (Parameter) —— 参数是一个变量规格,用在调用行为特征时传入或传出信息;

(P100) 参数方向种类 (Parameter Direction Kind) —— 参数方向种类是一个枚举类型,定义用于说明参数方向的文字;
in - 输入参数;
inout - 输入之后,行为特征可以改变此参值,然后再输出;
out - 输出参数,执行行为特征期间输出的参数;
return - 返回参数,行为特征执行结束之后返回的参数;

--- 4.4 操作 ---
(P102) 操作 (Operation) —— 操作是类元行为特征,指定调用关联行为的名称、类型、参数和约束;

--- 4.5 类 ---
(P107) 类 (Class) —— 类描述一个对象集合,它们共享相同的特征、约束和语义规格;

(P110) 性质 (Property) —— 性质是一个结构特征;

(P112) 关联 (Association) —— 关联描述元组的集合,它们的值引用类型化的实例。关联的一个实例叫做链接;

(P119)
聚合种类 (Aggregation Kind) —— 聚合种类是一个枚举类型,它指定定义性质聚合种类的文字;

UML预设了三种聚合种类:
None : 关联;
Shared : 聚合;
Composite : 组合;

--- 5.1 数据类型 ---

(P122) 数据类型 (Data Type) —— 数据类型是一个类型,它的值没有标识(即纯值)。数值类型包括基本内建的类型,也包括枚举类型;

(P123) 基本类型 (Primitive Type) —— 基本类型定义预定义的数据类型,不带任何相关的子结构(即没有部件)。一个基本数据类型会有定义于UML之外的算法和运算;

(P124)
枚举 (Enumeration) —— 枚举是一个数据类型,它的值作为枚举文字枚举于模型心;

枚举文字 (Enumeration Literal) —— 枚举文字是用户为枚举定义的数据类型;

--- 5.2 包 ---
(P125) 包 (Package) —— 包用于将元素分组,并为被分配元素提供名称空间;

(P128)
包合并 (Package Merge) —— 包合并定义一个包如何通过合并内容扩展另一个包;

包合并的图示为带箭头虚线,且于虚线旁标记 <<merge>>并由来源包指向目标包,意指将目标包的内容并入来源包;

--- 5.3 依赖 ---

(P133)
依赖 (Dependency) —— 依赖是一种关系,表示单个模型元素或模型元素集合对于其规格或实现而需要其他模型元素。这意味着依赖元素的完整语义也在语义上或结构上依赖于供应者元素的定义;

具名元素 (Named Element) —— 具名元素是模型可以有名称的元素;

(P134) 依赖的图示是带箭头的虚线,由依赖元素指向供应者元素;

(P137) 依赖并没有继承类元,意味着在执行期间它并没有对应的实例;

(P137) 使用关系 (Usage) —— 使用是一种关系,在这种关系中,一个元素为了完整实现或操作而需要另一个元素(或元素集合)。在元模型中,使用是一种依赖,在这种依赖中,客户需要供应者的存在;

(P139) 许可 (Permission) —— 许可表示同意客户模型元素有权访问供应者模型元素。换句话说,表示客户需要访问供应者的一些或所有组成元素。供应者元素给予客户访问一些或所有组成元素的许可;

(P140) 抽象 (Abstraction) —— 抽象是一种关系,它把代表不同抽象级别或不同视角的同一概念的两个元素或元素集合联系在一起。在元模型中,抽象是一种在供应者和客户之间映射的依赖;

(P142) 实现 (Realization) —— 实现是两个模型元素集合之间的一种特化的抽象关系。一个代表规格(供应者),另一个代表实现(客户)。实现可以用于逐步精化、优化、转化、模板、模型合成、框架组合等的建模;

(P143)
替代 (Substitution) —— 替代是两个类元之间的一种关系,表示替代类元符合契约类元指定的契约。这意味着替代类元的实例在运行时可以在需要契约类元实例的地方代替它;

替代 != 泛化;

(P145)
实现 (Implementation) —— 实现是类元和接口之间一种特化的实现关系。实现关系表示实现类元遵从接口指定的契约;

行为类元 (Behaviored Classifier) —— 行为类元可以拥有实现;实现的图示是带三角形的虚线;

(P147) 接口 (Interface) —— 接口是一种类元,代表关于一组内聚的公共特征和义务的声明。在某种意义上,一个接口指定一种必须被任何实现该接口的类元实例履行的契约。和接口关联的义务以各种约束(例如前置和后置)条件或协议规格的形式存在,并且可能对接口的交互施加次序限制;

--- 6.1 流程 ---

(P154)
活动节点 (Activity Node) —— 活动节点是由活动边连接的活动流中的点的抽象类;

活动边 (Activity Edge) —— 活动边是两个活动节点之间有向连接的抽象类;

(P160)
控制流 (Control Flow) —— 控制流是一条边,在前一个活动节点完成之后开始一个活动节点;

控制流无法携带数据或对象;

(P161)
对象流 (Object Flow) —— 对象流是一条活动边,可以有对象或数据通过它传递;
说明:
1. 对象流可以携带数据或对象;
2. 对象流其中一个端点必须是对象节点,另一端必须是其他的活动节点;控制流的两个端点则都不可以是对象节点;

--- 6.2 节点 ---

(P163) 活动 (Activity) —— 活动是参数化行为作为协同的次级单元顺序的规格,其中的个体元素是动作。动作激发活动;

(P167)
执行节点 (Executable Node) —— 执行节点是可以执行的活动节点的抽象类,用作异常处理器的附加点;

动作 (Action) —— 动作是可执行的活动节点,它是活动中可执行功能的基础单元,区别于动作之间的控制和数据流。动作的执行表达了建模系统中的转换或处理,不管是计算机系统还是其他系统;

(P168) 对象节点 (Object Node) —— 对象节点是一个抽象活动节点,它是活动中定义对象流的一部分;

(P170) 活动参数节点 (Activity Parameter Node) ——活动参数节点是作为活动输入输出的一个对象节点;

--- 6.3 动作 ---

(P172) 引脚 (Pin) —— 引脚是动作的输入输出对象节点;倘若动作有对应到对象的操作,引脚的个数和类型就要与操作的参数相同;

(P173)
输出引脚 (Output Pin) —— 输出引脚是持有动作产生的输出值的引脚。输出引脚是通过对象边到其他动作的对象节点和移交值;

输入引脚 (Input Pin) —— 输入引脚是持有动作消费的输入值的引脚。输入引脚是通过对象边来自其他动作的对象节点和接收值;

(P176) 值引脚 (Value Pin) —— 值引脚是一个输入引脚,它给不是来自进入对象流边的动作提供一个值;

--- 6.5 控制节点 ---

(P177) 控制节点 (Control Node) —— 控制节点是协调活动中的流的抽象活动节点;

(P178) 起始节点 (Initial Node) —— 起始节点是一个控制节点,当活动被引发时,流从该节点开始;

(P179)
终止节点 (Final Node) —— 终止节点是一个抽象控制节点,活动中的流从该节点停止;

活动终点 (Activity Final Node) —— 活动终点是活动中所有流停止的终止节点;

(P183) 合并节点 (Merge Node) —— 合并节点是一个控制节点,它把多个备选流合并到一起。合并节点不用于同步并发流,而是从若干备选流中接受一个流;

(P184) 判断节点 (Decision Node) —— 判断节点是在向外的流之间作出选择的控制节点;

--- 7.1 交互 ---

(P188)
交互 (Interaction) —— 交互是一个行为单元,它聚集于可连接元素之间可观测的信息交换;

交互片段 (Interaction Fragment) —— 交互片段是最一般的交互单元的抽象表示。交互片段是一片交互。每个交互片段本身在概念上类似于一个交互。交互片段是一个抽象类,是具名元素的特化;

--- 7.2 消息 ---

(P191) 消息 (Message) —— 消息定义交互生命线之间的特定通信。消息是一个具名元素,它定义交互中一种特定的通信。通信可以是发起一个信号,调用一个操作,创建或摧毁一个实例。消息不仅指定分派中的执行发生所给的通信种类,而且指定发送者和接收者。通常,一条消息关联两个事件发生,发送的事件发生和接收的事件发生;

(P191) 消息端 (Message End) —— 消息端是一个抽象具名元素,表达在消息端上可以发生什么;

(P199)
事件发生 (Event Occurrence) —— 事件发生表达动作关联的时刻。一个事件发生是基本的交互语义单元。事件发生的序列是交互的含义。消息可以通过异步信号或操作调用发送。同样,它们被消费的接受或动作接收;事件发生是交互片段和消息端的特化;事件发生沿着生命线排序;事件发生的命名空间是包含它的交互;

执行发生 (Execution Occurrence) —— 执行发生是生命线内行为单元的实例。因为执行发生会持续一段事件,它表达为两个事件发生,开始事件发生和完成事件发生。执行发生是一个交互片段;

(P201) 一般次序 (General Ordering) —— 一般次序表达两个事件发生之间的二元关系,描述一个事件发生必须以有效的轨迹在另一个之前发生。这个机制提供了定义没有特定次序的事件发生的偏序能力。一般次序是具名元素的特化。一般次序可以出现在交互的任何地方,但只是在事件发生之间;

(P203) 生命线 (Lifeline) —— 生命线表达了交互中的个体机制执行者。部件和结构特征的多重性可以大于1,但生命线只代表一个交互实体;生命线是具名元素的特化;

(P209) 状态不变式 (State Invariant) —— 状态不变式是对生命线状态的约束。“状态”也意味着生命线的最终属性值;

(P211) 终止 (Stop) —— 终止是一个事件发生,定义终止发生的生命线所指定的实例的结束;

--- 8.1 用例于类元 ---

(P214)
用例 (Use Case) —— 用例是系统执行的动作集合规格,它为一个或更多系统的执行者或其他相关人产生一个可观察的结果值;

类元 (Classifier) —— 以自身用例的能力扩展一个类元。虽然拥有类元通常代表被拥有用例所应用的主题,但也不一定,原则上,同一个用例可以应用于多个主题,由一个用例的主题关联角色识别;

(P215) 用例名称可以放置在椭圆图示的内部或底部。再者,因为用例是一种类元,所以它也可以采用类元的矩形图示,不过矩形内部的右上角会有小椭圆的标记;

--- 8.3 执行者 ---

(P223) 执行者 (Actor) —— 执行者指定与主题交互的用户或其他系统扮演的角色(术语“角色”在这里是非形式地使用,不一定暗示这个规格在别处发现的该术语的技术定义);

(P224) 包含关系 (Include) —— 包含关系定义一个用例包含在另一个用例中定义的行为;

(P228) 扩展关系 (Extend) —— 从一个扩展用例到一个被扩展用例的关系,说明扩展用例定义的行为如何以及何时插入被扩展用例定义的行为;
说明:
1. 相较于包含关系的一定要执行的特性,扩展关系则是一种可选择是否执行的关系;
2. 扩展关系是由扩展用例指向基用例;包含关系是由基用例指向被包含用例;
3. 包含关系和扩展关系有下列三项差异:
a. 箭头方向相反。在包含关系中,基用例指向被包含用例;在扩展关系中,扩展用例指向基用例;
b. 被包含用例一定要执行;扩展用例可以不执行;
c. 包含关系中的基用例不能独立存在,必须依赖它的包含用例;扩展关系中的基用例能够独立存在,不依赖它的扩展用例;

(P232) 扩展点 (Extension Point) —— 扩展点识别用例行为中的点,在那里该行为可以被其他(扩展)用例的行为按照扩展关系指定的方式扩展;

--- 9.3 共同行为 ---

(P245) 行为 (Behavior) —— 行为是上下文类元随着时间改变状态的规格。这个规格既可以定义可能行为执行,也可以定义选择性展示感兴趣的子集或可能执行。后一种形式通常用于捕获例子,例如特定执行的轨迹;

(P250) 行为类元 (Behaviored Classifier) —— 可以有定义于名称空间中的行为规格的类元。其中一个可以说明类元本身的行为;

(P252) 活动 (Activity) —— 活动通过主体字符串说明行为;

(P253) 不透明表达式 (Opaque Expression) —— 不透明表达式提供准确定义不透明表达式行为的机制。不透明表达式由返回一个结果的限制行为定义;

(P271)
特征 (Feature) —— 特征声明类元实例的行为或结构特征;

结构特征 (Structural Feature) —— 结构特征是类元的类型化特征,说明类元实例的结构;

行为特征 (Behavioral Feature) —— 行为特征是类元的特征,说明类元行为的一个方面;
分享到:
评论

相关推荐

    绿色版的UML工具JUDE-Community

    在软件开发过程中,UML(统一建模语言)是一种重要的图形表示工具,用于描述、构建和文档化软件系统。它通过一系列图形符号来表达软件设计的各个层面,如用例图、类图、序列图等。当开发者需要进行系统分析和设计时...

    ArgoUML-0.34-setup.exe

    ArgoUML-0.34-setup.exe

    Python库 | protobuf-uml-diagram-0.7.tar.gz

    资源分类:Python库 所属语言:Python 资源全名:protobuf-uml-diagram-0.7.tar.gz 资源来源:官方 安装方法:https://lanzao.blog.csdn.net/article/details/101784059

    computer-uml.rar_computer-uml_ssd3 uml_uml-customer-system

    本资料集“computer-uml.rar”包含了与计算机UML相关的图像和描述,特别是针对“uml-customer-system”的设计,这是对一个基于SSD3技术的客户系统的详细建模。 首先,我们要理解UML的基本概念。UML是一种标准化的...

    ArgoUML-0.34-setup.zip

    **ArgoUML简介** ArgoUML是一个开源的、基于Java编写的统一建模语言(UML)建模工具。这个工具旨在提供一个简单、免费且易于上手的环境,帮助用户创建、编辑和管理各种UML模型。在UML领域,ArgoUML是一个广受欢迎的...

    UML建模实例-课程注册系统

    UML建模实例-课程注册系统 UML建模实例-课程注册系统是一个综合的软件构架文档,旨在为Wylie College开发课程注册系统。该系统旨在支持联机课程注册,提供了课程注册、学生信息维护、教授信息维护、成绩提交、成绩...

    UML大作业-旅游预定系统.docx

    旅游预订系统是一个旨在简化旅游规划和预订流程的软件应用,它结合了UML(统一建模语言)的设计方法,以实现高效、用户友好的服务。本文将深入探讨该系统的需求、设计模型及其功能。 一、项目概述 旅游预订系统的...

    基于UML的J-QQ即时通信系统分析与设计

    ### 基于UML的J-QQ即时通信系统分析与设计 #### UML统一建模技术概述 UML(Unified Modeling Language),即统一建模语言,是20世纪90年代末由Grady Booch、James Rumbaugh和Ivar Jacobson三位面向对象建模方法论...

    UML参考手册--基本概念

    UML参考手册--基本概念,UML参考手册--基本概念

    UML大作业-教务管理系统.docx

    ### UML大作业-教务管理系统 #### 一、问题背景与需求分析 近年来,随着高等教育的普及和发展,各大高校的招生规模迅速扩大,随之而来的是教务管理工作的复杂度和工作量也随之增加。传统的教务管理模式已经无法...

    argouml-diagrams-sequence.jar.zip

    首先,"argouml-diagrams-sequence.jar.zip"是一个压缩文件,其中包含的主要元素是"argouml-diagrams-sequence.jar"和"mof-license.txt"。前者是ArgoUML序列图插件的可执行文件,用于扩展ArgoUML的功能,让用户能够...

    uml设计工具--简单

    根据给定的信息,我们可以推断出这是一篇与UML设计工具相关的文章,但实际内容似乎是乱码或者非相关文字。不过,我们仍然可以从标题、描述以及部分标签中提取一些有关UML设计工具的重要知识点。 ### UML设计工具...

    ArgoUML-0.30-setup.zip

    它的发布版本"ArgoUML-0.30-setup.zip"包含了必要的安装程序,方便用户快速便捷地进行安装。 在下载并解压"ArgoUML-0.30-setup.zip"后,用户会发现其中包含两个重要文件:一是"jre-6u45-windows-i586.exe",这是...

    UML课程设计--工资管理系统方案.doc

    UML课程设计--工资管理系统方案.doc

    The Elements of UML Style--UML风格

    《The Elements of UML Style--UML风格》 教人如何画好UML的很必要,

    北航UML课件---北航考博软件工程UML考试范围

    【标题】"北航UML课件---北航考博软件工程UML考试范围"揭示了这组资料的核心内容,即北京大学航空航天大学(北航)针对博士研究生入学考试中的软件工程科目,重点聚焦于统一建模语言(UML)的学习与复习。UML是一种...

    UML建模实例--保险、图书馆、医院.rar

    UML建模实例--保险、图书馆、医院.rar

    UML建模实例--保险、图书馆、医院

    UML建模实例--保险、图书馆、医院

Global site tag (gtag.js) - Google Analytics