UML学习笔记

当年学习UML时的期末复习笔记，分享一下~

UML Learning Notes

UML

• basic building block

  • thing

    • structural
    • behavior
    • grouping
    • annotation

  • relationship

    • dependency
    • association
    • generalization
    • realization
  • diagram

• rule

  • name
  • scope
  • visibility
  • integrity完整
  • execution

• common mechanism

  • specification
  • adornment
  • common division
  • extensive mechanism扩展机制
    • stereotype版型
    • tagged value
    • constraint约束

• view of architecture

  • logical
  • implementation
  • process
  • deployment
  • use case

---

Use case diagram

Actor

参与者是系统以外的与系统交互的人或事 物，包括人、设备、外部系统等

Use case

用例定义了一组相关的由系统执行的动作序 列，将有价值的可见结果提供给某个参与 者。

Relationship

• association

• 泛化（generalization）：抽取一些用例共 同的属性，定义一个基础用例

• 包含（include）：一个用例的执行要用到 另外的用例
• 扩展（extend）：把新的用例（功能）插入 到已有用例（基础用例）

Methods

• Establish the context of the system by identifying the actors that surround it.

• For each actor, consider the behavior that each expects or requires the system to provide.

• Name these behaviors as use cases.

• Factor common behavior into new use cases that are used by others; factor variant behavior into new use cases that extend more main line flows.

• For each use case, describe the typical interactions between the actors and the system.

• Model these use cases, actors, and their relationships in a use case diagram.

• Adorn these use cases with notes or constraints that assert nonfunctional requirements.

1. 找出系统外部的参与者和外部系统, 确定系统边界 和范围
   1. 确定每一个参与者所期望的系统行为
   2. 把这些系统行为命名为用例
   3. 使用泛化、包含、扩展等关系处理系统行为的公 共或变更部分
   4. 编制每一个用例的脚本
   5. 绘制用例图
   6. 区分主要事件流和异常事件流, 如果需要, 可以把 异常事件流处理为单独的用例
   7. 细化用例图, 解决用例间重复与冲突的问题

Class diagram

+ public
- private
# protected
~ package

• aggregation聚合 （空心）

Some objects are weakly related like a computer and its peripherals

• composition组合 （实心）

Some objects are strongly related like a tree and its leaves

Relationship

泛化 （实线空心三角箭头）

关联 （实线）

聚合 （空心菱形）

组合 （实心菱形）

实现 （虚线空心三角箭头）指向接口

依赖 （虚线箭头）

强弱关系：组合>聚合>关联>依赖

OOD Principles

• 开闭原则：Open/Closed Principle, OCP

  软件实体在扩展性方面应该是开放的，而在更改性方面应该是封闭的

  为了满足开闭原则，设计时应尽量使用接口 进行封闭, 采用抽象机制, 并利用OO中的多态 技术

• Liskov替换原则：Liskov Substitution Principle, LSP

  子类可以替换父类出现在父类能出现的任何地方

• 依赖倒置原则：Dependency Inversion Principle, DIP

  依赖关系应该是尽量依赖接口(或抽象类)，而不是依赖于具体类

  抽象不应该依赖于细节, 细节应该依赖于抽象

  要针对接口编程, 不要针对实现编程

• 接口分离原则：Interface Segregation Principle, ISP

  使用多个专门的接口比使用单一的总接口要好

Object diagram

An object diagram is a snapshot of the objects in a system at a point in time.

对象图表示一组对象和它们之间的关系

对象图是一个系统的详细状态在某时刻的快照

对象图可以看作是类图在某个时刻的实例

对象图的建模元素

• 对象

• 对象之间的关系

Package diagram

A package is a grouping construct that allows you to take any construct in the UML and group its elements together into higher-level units.

A package diagram shows packages and their relationships.

Elements:

• class
• interface
• component
• node
• use case
• package…

Package -grouping thing

对语义上相关的元素进行分组

提供配置管理单元

在设计时，提供并行工作的单元

提供封装的命名空间，其中所有名称必须唯一

Relationship

Supplier<——-Client

• << import>>

  Public elements of the supplier namespace are added as public elements to the client namespace.

• << access>>

  Public elements of the supplier namespace are added as private elements to the client namespace.

• <>

  An element in the client uses an element in the supplier in some way. The client depends on the supplier.

• << trace>>

  usually represents an historical development of one element into another more refined version. It is an extra-model relationship.

• <>

  The client package merges the public contents of its supplier packages. This is a complex relationship only used for metamodeling - you can ignore it.

• Nested packages

  small ⊕—- big

Interaction diagram

• Sequence Diagram 顺序图（序列图）

  • 对象（Object，包括Actor的实例）
  • 生命线（Lifeline）
  • 控制焦点（Focus of control）
  • 消息（Message）

• Communication Diagram 通信图（协作图）

  通信图描述系统中对象之间通过消息进行的交互，强调参加交互的对象的组织结构

  通信图有对象链接

  通信图必须有消息顺序号

  顺序图强调消息的时间顺序，通信图强调参 加交互的对象的组织，两者可以相互转换

• Timing Diagram 定时图（时序图）

  坐标轴交换了位置，改为从左到右来表示 时间的推移
  用生命线的“凹下凸起”来表示状态的变化，每个水平位置代表一种不同的状态
  可显示一个度量时间值的标尺，用刻度表示时间间隔

• Interaction Overview Diagram 交互概述图

  交互概述图是将活动图和顺序图嫁接在一起的图

  它将活动节点进行细化，用一些小的顺序图 来表示活动节点内部的对象控制流

GRASP：“通用职责分配软件模式”

• Information Expert(信息专家) —把职责分配给信息专家
• Creator(创建者)—把接收和处理系统事件消息的职责分配给控制者
• Low Coupling(低耦合) —把创建类A实例的职责分配给一个在任何情况下都与被创建对象相关联的创建者
• High Cohesion(高内聚) —分配职责时要保持低耦合
• Controller(控制器)—分配职责时要保持高内聚

Information Expert

信息专家模式核心思想：把职责分配给具有 完成某项职责所需信息的个体。
信息专家模式在职责分配中使用得非常广 泛，它是对象设计中经常使用的基本指导原 则。
职责的履行需要信息，而信息往往分布在不 同的对象中。这就意味着许多“部分”的信息专 家有时需要协作才能来完成一个任务。

Problem It Solves: What is a basic principle by which to assign responsibility to objects?

Solution: Assign a responsibility to the class that has the information needed to fulfill it.

Creator

创建者模式指导怎样分配“与创建对象”相关的职 责。创建者模式的基本目的是找到一个在任何情况 下都与被创建对象相关联的创建者，选择这样的类 作为创建者能支持低耦合。

集合聚集了部分,容器包含了内容,记录器记录了被 记录的数据，这些类之间的关系在类图中非常普 遍。创建者模式建议：封装的容器类和记录器类是 创建“自己包含或者记录的元素”的很好候选者

Problem: Who should be responsible for creating a new instance of some class?

Solution: Assign class B the responsibility to create an instance of class A if one or more of the following is true:

• B aggregates A objects.
• B contains A objects.
• B records of A objects.
• B closely uses A objects.
• B has the initializing data that will be passed to A when it is created.
• B is a creator of A objects.

Low Coupling

低耦合模式鼓励职责分配时不增加耦合性。 从而避免了高耦合可能产生的不良后果。

优点：不受其它组件改变的影响；便于单独 理解；重用方便

Problem: How to support low dependency, low change impact, and increased reuse?

Solution: Assign a responsibility so that coupling remains low.

High Cohesion

高内聚模式鼓励职责分配时保持较高的内聚性。

优点：使设计的清晰性和易于理解性得到提高；维护和扩展得到简化；常常支持低耦合；重用性提高。

Controller

控制器是负责接收或者处理系统事件的对象。

把接收或处理系统事件的职责分配给代表整个系统、设备或子系统的类、表示用例场景的类，如< UCName>Handler， Coordinator或Session

Problem: Who should be responsible for handling an input system event?

Solution: Assign the responsibility for receiving or handling a system event message to a class representing one of the following choices:

State machine diagram

A state machine models the lifetime of a single object.

状态机图描述对象在整个生命周期的动态行为：它可能经历的状态，什么情况下它离开 一个状态到达另一状态，在这个过程中它做了什么。

想要关注一个对象跨越多个用例的行为

Methods

Set the context for the state machine.

Establish the initial and final states for the object.

Decide on the events to which the object may respond.

Starting from the initial state to the final state, lay out the top-level states the object may be in. Connect these states with transitions triggered by the appropriate events. Add actions to these transitions.

Identify any entry or exit actions.

Expand these states as necessary by using substates.

Check all events and actions.

Check the state machine against expected sequences of events and their responses.

寻找主要的状态

确定状态之间的转换

细化状态内的活动和转换

用复合状态展开细节

Activity diagram

An activity diagram shows the flow from activity to activity.

活动图用来描述事情进行的流程，是UML中 对系统行为建模的一种常用工具
活动图描述系统的控制流：从一种活动转换 到另一种活动的整个过程
活动图可以对系统的工作流程建模，也可以 对具体的操作建模

Model elements

Initial nodes and Final nodes

Activity nodes

Control flows

Decision and Merge nodes

Fork and join nodes

Partitions and Swim Lanes

Object Flows

Decision and merge nodes

A decision node is a control node that has one input edge and two or more alternate output edges

Fork and join nodes

Forks nodes model concurrent flows of work

Swim lane & Partitions

You’ll find it useful, especially when you are modeling workflows of business processes, to partition the activity states on an activity diagram into groups, each group representing the business organization responsible for those activities

If you want to show who does what, you can divide an activity diagram into partitions

Component diagram

Component diagrams show the organization of and dependencies among a set of components

Use component diagrams when you are dividing your system into components and want to show their interrelationships through interfaces or the breakdown of components into a lower-level structure.

Model elements

• Component 构件
• Interface 接口
• Dependency 依赖关系

Components

A component is a replaceable part of a system that conforms to and provides the realization of a set of interfaces

构件和类

类描述软件设计的逻辑组织和意图，构件描述软件设计的物理实现
构件可以部署，类不能部署

类可以拥有操作和属性，而构件仅拥有可以通过其接口访问的操作

Deployment diagram

A deployment diagram models the mapping between the software architecture and the physical system architecture.

部署图描述系统硬件的拓扑结构和软件在硬件上的配置。

Model elements

• 节点（Node）
• 连接（Connection）

Nodes

A node is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, processing capability

Graphically, a node is rendered as a cube

节点与构件的区别

构件往往表示一个软件部件，节点往往表示 一个硬件部件
构件是参与系统执行的事物，节点是执行构件的事物
构件表示逻辑元素的物理打包，节点表示构 件的物理部署

UP

统一过程(Unified Process)是一个将用户需 求转化为软件系统所需要完成的一系列任务 的框架，规定了完成各项任务的步骤。

Process model

统一过程是一个二维生命周期模型，纵轴代表 核心工作流，横轴代表时间。一个工作流可 以分配在若干恰当的时间阶段完成；一个阶 段可以涉及多项工作流

Phases 阶段

• Inception初启

  Life Cycle Objectives - conditions of satisfaction:
  System scope has been defined
  Key requirements for the system have been captured. These have been defined and agreed with the stakeholders
  An architectural vision exists. This is just a sketch at this stage
  A Risk Assessment
  A Business Case
  Project feasibility is confirmed
  The stakeholders agree on the objectives of the project

• Elaboration细化

  Lifecycle Architecture - conditions of satisfaction:
  A resilient, robust executable architectural baseline has been created
  The Risk Assessment has been updated
  A project plan has been created to enable a realistic bid to be formulated
  The business case has been verified against the plan
  The stakeholders agree to continue

• Construction构造

  Initial Operational Capability - conditions of satisfaction:
  The product is ready for beta testing in the user environment

• Transition移交

  Product Release - conditions of satisfaction:
  Beta testing, acceptance testing and defect repair are finished
  The product is released into the user community

Characteristics

Use case (requirements) driven 用例驱动
Architecture centric 构架中心
Iterative and incremental 迭代和增量
…