面向对象技术与UML期末复习

Object Oriented Technology and UML Review

Author : Jerome Exam Date : 11.8 Thu. 6-7 Lesson Classroom : J1-211

Overview and Introduction

Key points in UML Review

UML means Unified Modeling Language , 统一建模语言 in Chinese.

Important goal of software engineering : solving the software crisis.

Software complexity is inherent
. Reduce and control the complexity of
software.

The basic method of controlling
software complexity: Divide, Abstract, Modularization, Information hiding.

Software Process Model :

Waterfall model , prototype model , Evolutionary model(incremental model, spiral model)

UML is a modeling language, not a method， UML is independent of the software
development process

Objects interact through messages.

In UML, object is the class instance, collaboration is
the instance of use case, link is the instance of
association…

UML is not a programming language

RUP is an iterative software development process
framework : 统一迭代开发过程

RUP(rational unified process) : RUP uses UML as standard language for
modeling software-intensive systems

Six Best Practices Of RUP:

1. Develop iteratively

   整个迭代的渐进式软件开发过程包括4个阶段：初启
   (Inception)、细化(Elaboration)、构造
   (Construction)和移交(Transition)。每个阶段可以根据需要细分为多次迭代。

2. Manage requirements

3. Use components

4. Model visually

5. Verify quality

6. Control changes

统一过程的特点是：用例驱动、以构架为中
心、迭代和增量的。

The UML is the foundation for successful
visual modeling

Rules of the UML

Names, Scope, Visibility, Integrity, Execution.

What’s UML?

1. Unified Modeling Language.
2. The UML may be used to visualize, specify,
   construct, and document the artifacts of a
   software-intensive system

What’s the difference between UML and programming language?

Which three parts make up the UML? : Building blocks, Rules and Common Mechanisms

The Main Phases of the software Life cycle:

需求分析 设计模型 编码 测试 维护

The main phases of RUP: 初启 细化 构造 移交

总结：

Class Diagram

Belong to Structure Diagram

Concept

1. Represent

   

   一般而言，类名是名词，以大写字母打头，避免使用特殊记号

   Form of Attribute:

   [visibility] name [‘:’ type][‘[‘ multiplicity] ‘]’][‘=’ initial- value][property-string {‘,’ property-string}]

   [可见性] 属性名[:类型][ ‘[’ 多重性[次序] ‘]’ ][= 初始值][{特 性}]

   Visibility:

   + Public

   # Protected

   - Private

   ~ Package

   Multiplicity:

   

   Property-string : Name:String=“COSE SEU.”{readOnly}

   Operation

   [visibility] name [‘(‘ parameter-list ‘)’][‘:’ return-type]
   [property-string {‘,’ property-string}]

   [可见性] 操作名[(参数列表)][:返回类型] [{特性}]

   Example:

   +display (): Location

   set(n : Name, s : String)

   -attachXWindow(xwin: XwindowPtr)

   Constraints: A constraint is rendered as a string
   enclosed by brackets and placed near
   the associated element

   

2. Advanced Class

   • Abstract Class

     用斜体或用构造型

     

   • Interface

     

   • Association Class(关联类)

     两类间存在多对多关系，属性不容易归到其中一个类中

     

   • Parameterized Class(模板类)

     可以根据占位符或参数来定义类，而不用说明属性、方法返回值和方法参数的实际类型

     

   • Active Class(主动类)

     主动类的实例称为主动对象，一个主动对象拥有一个控制线程并且能够控制线程的活动，具有独立的控制权

     表达方式：类两边加垂直线

     

   • Nested Class（嵌套类）

     嵌套类存在于外层类的名字空间中，因此只
     有外层类或外层类的对象才能访问它或它的
     实例

     

3. Relationships in class

   1. Generalization 泛化

      特殊事务与一般事务的关系, “is a kind of”

      Graphically, generalization is rendered as a solid directed
      line with a large unfilled triangular arrowhead, pointing to
      the parent

      

      在Java中，其实就是sub-class extends base-class

   2. Association

      

      Name of Association

      用来描述关联, 通常是动词或者动词短语

      可以前缀或后缀一个小黑箭头表明阅读的方向

      

      关联的角色

      关联两端的类可以某种角色参与关联, 应该用名词或名词短语描述角色的语义

      

      多重性表明在任意时刻关系所能够涉及的对象数目,对象可去可留，但多重性约束任意时刻对象的数目

      Association Class

      In an association between two classes,
      the association itself might have
      properties

      

      Constraint of Association

      

      Qualification of Association

      

      带有限定符（qualifier）的关联称为限定关联(qualified association)，作用是给定关联一端的一个对象和限定符值，可确定另一端的一个对象或对象集

      Arity of Association（关联种类）

      Recursive or Reflexive Association: 自反关联

      

      Binary Association: 二元关联

      

      N-ary Association: N元关联

      

   3. Aggregation,Composition

      聚合是一种特殊形式的关联，表示类之间的整体与部分的关系,部分可以独立于聚合而存在

      Aggregation is specified by adorning a plain
      association with an unfilled diamond at the whole
      end

      

      

      组合是一种强形式的聚合，部分每次只能属于一个整体，整体唯一地负责处理它的部分，包括创建和销毁

      如果整体销毁，必须将它所有的部分销毁或把处理权交给其它对象

      组合关系中的整体与部分一般具有同样的生存期

      

      Aggregation: has-a

      Composition: contains-a

   4. Realization

      

      

   5. Dependency

      依赖表示两个或多个模型元素之间语义上的关系，对一个元素的改变可能影响其它元素。

      在类中，依赖由各种原因引起，如

      一个类向另一个类发消息

      一个类是另一个类的数据成员类型

      一个类是另一个类的某个操作参数类型

      ……

      单向表示：

      

   conclusion

   关联、聚合、组合、依赖强弱关系比较：

   组合>聚合>关联>依赖

   

4. Derived Associations and Attributes

   

5. Stereotype

   

三种主要的类版型：

1. 边界类(boundary class)

   边界类位于系统与外界的交界处, 如窗体类,与外设交互的类

   

2. 实体类(entity class)

   实体类描述要保存到持久存储体中的信息，如：数据库，各种形式的数据文件

   

3. 控制类(control class)

   控制类是主要负责控制其它类工作的类

Three Perspectives of Class Diagram

概念层（conceptual）类图

说明层（specification）类图

实现层（implementation）类图

对比：

Method to modeling

1. How to find classes

   Determine candidate classes from the nouns
   of use case description

   Use CRC (Class responsibility collaborator)
   method to discover classes

   Use the division of Boundary, Control, and
   Entity Classes

   Determine classes according to design
   patterns

   Find classes under the guidance of the
   software development process

2. Suggestions

   Do not try to use all of the symbols

   Do not fall into the details too early

3. Principles of Object Oriented Class Design

   Open Closed Principle (OCP) 开闭原则

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

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

   示例:

   

   Liskov Substitution Principle (LSP) Liskov 替换原则

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

   

   Dependency Inversion Principle (DIP) 依赖倒置原则

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

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

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

   Interface Segregation Principle (ISP) 接口分离原则

4. Hints and Tips of Object Oriented Desgin

   Names of similar operations in different
   classes should be the same

   Comply with existing conventions

   Design simple classes

   Define simple operations

   The levels of generalization should be
   appropriate

5. Style of UML Class Diagram

   Be Consistent with Attribute Names and
   Types

   Do Not Name Associations That Have
   Association Classes

   List Operations/Attributes in Order of
   Decreasing Visibility

   Always Indicate the Multiplicity

   Avoid a Multiplicity of “*”

   Do Not Model Every Dependency

   Place the Whole to the Left of the Part

   Don’t Worry About the Diamonds

Use Case Diagram

Belong to Behavior Diagram

Concepts

Two types of Requirements

1. Functional Requirements
2. Non-Functional Requirements

Three types of requirements technology

1. XP : User story in extreme programming
2. FDD : Feature description in feature-driven development
3. RUP : Use case in rational unified process

Definition of Use Case:Use cases define interactions between external
actors and the system to attain particular goals

Considerations of using use case

1. 强调从最终用户的角度来理解软件系统的需求。
2. 描述用户怎样使用系统
3. 描述参与者如何与系统进行交互
4. 浅显易懂，方便客户和系统设计者之间的交流

Use case analysis is a part of object
oriented analysis and design? Ans : T

Relationships between use cases and collaborations

In general, every use case should be realized by one or
more collaborations

Graphically, a collaboration is rendered
as an ellipse with dashed lines:

Scenario

A scenario is a specific sequence of
actions that illustrates behavior

Scenarios are to use cases as instances are
to classes, meaning that a scenario is
basically one instance of a use case

Elements of Use Case Diagram

1. Use Case

2. Actor

   Although you’ll use actors in your models,
   actors are not actually part of the
   software application. They live outside
   the application within the surrounding
   environment

   Three ways to represent an actor:

   

3. Relation

   Generalization Relationships between Actors(泛化)

   直线+空三角箭头

   

   参照继承，表示一个一
   般性的参与者与另一个更为特殊的参与者之间的联系。

   Actors may be connected to use cases
   only by association

   Example:

   

   The actor and the
   use case communicate with one another,
   each one possibly sending and receiving
   messages

   Generalization among use cases is just like generalization among classes , exmaple:

   

   Include: 包含关系是指一个用例(基本用例，base
   use case)的行为包含了另一个用例(包含用
   例,inclusion use case)的行为。

   

Extend: An extend relationship is rendered as a
dependency, stereotyped as extend.

The base use case may stand alone, but under
certain conditions its behavior may be extended
by the behavior of another use case

This base use case may be extended only at
certain points called, not surprisingly, its
extension points.

表示基本用例在某个条件成立时，合并执行扩展用例。基本用例独立于扩展用例而存在，只是在特定的条件下，它的行为可以被另一个用例(扩展)所扩展。

Examples:

“is a” -> Genernalization , Extend

“has a” -> include

Attention : Association, generalization, and dependency are relationships. Include, extend are special forms of dependency.

Exmaples:

What’s the Use Case Specification?

A use case specification is a document used to
capture the specific details of a use case

Use case specifications provide a way to
capture the functional requirements of a system

Use case specifications provide a means of
organizing all of the different scenarios that
exist. They add detail beyond what is shown in
a use case diagram. They are a useful tool in
communicating with project stakeholders,
system users, business analysts, and
developers

Template:

Use Case Name

Brief description

Flow of events

Basic flow

Alternative flows

Special requirements

Preconditions

Postconditions

Extension Points

What does these mean?

Style of UML Use Case Diagram:

Begin Use-Case Names with a String verb, like Withdraw Funds.

边界：矩形框表示

Object Diagram

Belong to Structure Diagram

Representation : Object Name : Class Name , Property name = property value.

Place Your Primary Actor(s) in the Top
Left Corner of the Diagram

Draw Actors on the Outside Edges of a
Use Case Diagram

Name Actors with Singular, Domain-
Relevant Nouns

Object Diagram commonly contain : Objects , Links

You use object diagrams to model the
static design view or static process view of a system just as you do with class
diagrams, but from the perspective of
real or prototypical instances

Example:

Class Diagram and Object Diagram

Package Diagram

Belong to Structure Diagram

Package is a general-purpose mechanism for
organizing elements into groups.

The role of the package:

1. 对语义上相关的元素进行分组
2. 提供配置管理单元
3. 在设计时，提供并行工作的单元
4. 提供封装的命名空间，其中所有名称必须惟一

Represent:

Package can own:

class, interface, component, node, use case, package ….

Visibility:

‘+’ : Public

‘-‘ : Private

‘#’ : Protected

Stereotype of package

<<system>> : 正在建模的整个系统

<<subsystem>> : 正在建模的系统中某个独立的部分

<<façade>> : 为复杂包提供简略视图

<<stub>> : 分布式系统建模

<<framework>> : 框架是一个领域中的应用系统提供可扩充模板的体系结构模式

Relationships between Packages

• Dependency

  <<import>> : 最普遍的包依赖类型, 提供者包的命名空间将被添加到客户包的命名空间中

  <<access>> : 可以访问提供者包中的所有公共元素，但命名空间不合并。

  <<use>> : 以某种方式使用提供者包的公共元素，客户包依赖于提供者包。

  <<trace>> : 一个包到另一个包的历史发展，不常用。

• Generalization 较少用

Package Diagram

Example:

Steps of modeling package diagrams:

1. 浏览特定体系结构视图中的建模元素，找出语义或其它方面接近的元素，并把这些元素放到一个包中.
2. 对每个包找出可以在包外访问的元素，将其标记公有，把其它元素标记为受保护或私有.
3. 确定包之间的依赖关系、泛化关系。

包图建模原则:

1. REP(Reuse Equivalency Principle) : 考虑包的可重用单元,该原则倾向于把包做的越小越好。
2. CRP(Common Reuse Principle) : 不会一起使用的类不要放在同一个包中，该原则倾向于把包做的尽可能小。
3. CCP(Common Closure Principle) : 把需要同时改变的类放在同一个包中，该原则倾向于将包做的尽可能的大。
4. ADP(Acyclic Dependencies Principle) : 包之间的依赖关系不要形成循环

Style of UML Package Diagram

1. 同框架内的类属于同一个包
2. 位于同意继承层次上的类属于同一个包
3. 通过聚合或者组合关系相关联的类属于同一个包
4. 相互之间协作很多的类属于同一个包

Activity Diagram

Belong to Behavior Diagram

Concept

An activity diagram shows the flow from
activity to activity(描述事情进行的流程)

You use activity diagrams to model the
dynamic aspects of a system. For the
most part, this involves modeling the
sequential (and possibly concurrent)
steps in a computational process.

You can use activity diagrams to model a
workflow or an operation （活动图可以对系统的工作流程建模，也可以对具体的操作建模）

Example

Difference between activity diagram and flow chart

活动图能够表示并发活动，而流程图不能

活动图是面向对象的，而流程图是面向过程的

流程图着重描述处理过程，活动图着重表现系统行为

Constituent element

• initial node

  

• final node

  A final node is a control node at which a flow in an activity stops.

  Activity final nodes are notated as a solid circle within a hollow circle.

  

  Flow final nodes are noted as a circle with an “X”
  cross inside it

  

• Activity node(活动)

  描述事情进行的状态，用圆端矩形表示

• Control Flows(转换)

  当一个活动执行结束，控制流就会马上传递给下一个活动节点，在活动图中称之为“转换”

  与状态图不同，活动图的转换一般不需要特定事件的触发

  表示形式：

  

• Decision Node(分支)

  分支用菱形表示，它有一个进入转换（箭头从外指向菱形），一个或多个离开转换（箭头从菱形指向外）

• Guard Condition(监护条件)

  A condition that must be satisfied to enable an
  associated transition to fire.

  Representation : [ logical expression ]

  

• Merge(合并)

  A MergeNode is a control node that
  brings together multiple flows without
  synchronization.

  No guards are
  necessary on merge.

  

• Fork Node(分岔) and Join Node(汇合)

  A synchronization bar is rendered as a thick
  horizontal or vertical line, which we use to specify the forking and joining of these parallel
  flows of control.

  Represent:

  

• Swimlane(泳道)

  泳道将活动图中的活动分为若干区，泳道可以区分负责活动的对象，明确表示哪些活动是由哪些对象执行的。

  每个泳道必须有自己的名称,每个活动只能明确地属于一个泳道

  转换、分岔、汇合和对象流允许跨越泳道

  分支只属于一个泳道

  

  

• Object Flow(对象流)

  活动可以输入和输出对象，在活动图中可用对象流表示

  对象流还可以显示活动间对象角色、状态和属性值的变化

  

  

• Sub-activity(辅助活动图)

  活动图中包含的子活动图

  

• Join Specification(汇合描述)

  通过汇合描述对汇合点加以约束

  

• Signal Action(信号)

  信号是表示两个对象之间异步通信信息包的方法，当一个对象接收到一个信号时，信号事件将发生.

  

• Pin(引脚)

  可以用引脚可以表示活动节点所需的数据以及将要产生的数据。

  Example：

  

• Expansion Region(扩展区)

  在需要表达一个活动需要多次执行的时候，
  可以采用扩展区.

  Usually , Activity Edge arrows inside and outside the Expansion Region will distinguish input and output expansion nodes.

  Example:

  

Steps of Activity Diagram Modeling

1. Define the scope of the activity diagram
2. Add the initial node and final node
3. Add the activity node
4. Add the decision node
5. Identify parallel activities
6. Add the control flows

Style of UML Activity Diagram

• 确保离开决策点每个转移都有一个监护条件

  这可以确保建模人员已经考虑到这个决策点的所有可能情况

• 确保决策点上的监护条件形成一个完备集

• 监护条件不能重叠

• 确保每一个分岔都有对应的汇合，确保每个分岔只有一个进入转移

• 确保每个汇合只有一个退出转移

Interaction Diagram

Belong to Behavior Diagram

交互图显式地描述对象如何交互以提供特定的系统行为

Sequence Diagram

顺序图显示参与交互的对象及对象之间消息交互的顺序。

Objects arranged along the X axis 水平方向为对象维

Messages, ordered in increasing time, along
the Y axis 竖直方向为时间维

Constituent elements of sequence diagram

概览图

1. Object 对象

   Three ways to represent

   

2. Lifeline 生命线

   Vertical dashed line that represents the existence of an object over a period of time

   由对象向下延申虚线

   

   All objects at the top of the lifeline are all aligned at the top of the diagram.(所有对象在顶端排列整齐)

3. Focus of control 控制焦点

   • Represent

   • A tall thin rectangle , shows the period of time when object is performing an action.

     Top of the rectangle is aligned with the start of the action. 顶端为动作开始。

     Bottom is aligned with its completion(can be marked by a return message.)

4. Message 消息

   • 消息用箭头表示，箭头的类型表示了消息的类型.

   • Message is asynchronous(异步) , the line has a stick arrowhead(->)

     Message is synchronous(a call) , line has a filled triangular arrowhead.

     A reply to a synchronous message(return from a call) , line is dashed arrow with a stick arrowhead.

     

   • 消息在生命线上的位置并不是消息发生的准确时间，只是一个相对位置.

   • Several kinds of messages:

     Call: 最常用的消息,表示调用某个对象的一个操作，可以是对象间的调用，也可以对本身。

     

     可以在符号上加上顺序编号、消息名称和参数.

     Return: 表示被调用的对象向调用者返回值。

     表示方法：虚线箭头,标明返回值

     

     Send 向对象发送一个信号，与调用不同，信号是一种事件，用来表示各对象间进行通信的异步激发机制。调用是同步机制，信号是异步机制。

     Create (Objects) by construct functions.

     

     Destroy: 利用析构函数

     目标对象的生命终止符号:大的叉形符号。

     

   • 消息编号:嵌套编号

   • 语法格式：

     [predecessor][guard-condition][sequence-expression][return-value:=] message-name ([argument list])

     [必须先发生的消息列表][监护条件][消息顺序表达式][返回值]消息名称([参数列表])

   • Structured control operators

     分支

     alt : 多条件

     opt : 单条件

     

     循环 : loop

     其中Loop(1,n):for(int i=1;i<n;i++) , Loop(10) : 执行10次

     

   • 常用操作符

     1. assert : 断言包含一个片段

     2. consider : 包含一个子片断和一个消息类型列表，只有列表中的消息类型可以出现在子片断中。

     3. ignore : 与consider相反，忽略列表中的消息类型。

     4. break：最长用来做异常处理。

     5. critical : 表示子片段是临界区域，通常用来表示一个原子性的连续操作。

     6. par : 两个或更多并发执行的子片段

     7. ref : 在一个交互图中引用其他的交互图。

        

   • 约束：constraint

     

Style

Strive for left-to-right ordering of messages (从左至右)

Name objects when several of the same type exist (同类对象命名)

Common Question:

如何在顺序图中表示消息的条件发送？

在消息上加监护条件

在消息名前加条件子句

使用文字说明

分成多个顺序图(每分支一图)

如：

Communication Diagram

示例:

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

Constituent elements:

• Object

• Link : 用来表示对象之间的语义连接,一般来说为关联的一个实例。

• Message similar with sequence diagram.

  为了说明交互过程中消息的时间顺序，需要给消息添加顺序号.(无层次、嵌套)

  顺序号是在消息的前面加一个整数，每个消息都必须有唯一的顺序号.

  

• 迭代标记：表示循环，用*号表示，还有迭代表达式

  

• 监护条件：通常应只列出主要的监护条件, 否则会影响其阅读。如果需要，尽可能还是通过顺序图来表示

建模步骤：

• 确定交互过程的上下文
• 识别参与交互过程的对象
• 确定对象之间的链接，以及沿着链的消息
• 从引发这个交互过程的初始消息开始，将随后的每个消息附到相应的链上
• 如果需要，消息编号可以表示为嵌套方式
• 如需要说明时间约束，则在消息旁边加上约束说明
• 如需要，可以为每个消息附上前置条件和后置条件

Style

1. Do Not Use Communication Diagrams to
   Model Process Flow(try activity diagram)
2. Create a Sequence Diagram When
   Sequence Is Important

Comparison

1. A sequence diagram emphasizes the time ordering
   of messages. A communication diagram emphasizes
   the organization of the objects that participate in an
   interaction

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

2. Because they both derive from the same information
   in the UML’s metamodel, sequence diagrams and
   communication diagrams are semantically equivalent.

3. 顺序图不同于通信图的特征：

   对象生命线

   控制焦点

4. 通信图不同于顺序图的特征：

   对象链接

   消息顺序号

Timing Diagram

如果要表示的交互有很强的时间特性，使用定时图。定时图是移中特殊的顺序图，其与顺序图的区别在于

坐标轴交换了位置，改为从左到右来表示时间的推移

用生命线的“凹下凸起”来表示状态的变化，每个水平位置代表一种不同的状态

可显示一个度量时间值的标尺，用刻度表示时间间隔

Example :

Interaction Overview Diagram

Interaction Overview Diagrams define
Interactions through a variant of Activity
Diagrams in a way that promotes
overview of the control flow

Interaction Overview Diagrams focus on the
overview of the flow of control where the nodes
are Interactions or Interaction Uses.

The Lifelines and the Messages do not appear at
this overview level.

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

可以看作活动图的变体: 它将活动节点进行细化，用一些小的顺序图来表示活动节点内部的对象控制流.

也可以看作顺序图的变体: 它用活动图来补充顺序图

Example:

Component Diagram

Belong to Structure Diagram

Concept

A diagram that shows the organization of
and dependencies among a set of
components.

Component diagrams address the static
implementation view of a system.

构件是定义良好接口并封装实现的物理单元。
构件图主要描述构件以及它们之间的关系。

• Component(构件)

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

  构件是一个系统或子系统中的封装单位，提供一个或多个接口，它是独立的，可替代的，是系统高层的可重用的部件。

  Component diagram has a higher level of
  abstraction than a Class Diagram.(较类图具有更高抽象度)

  Component and Class

  类描述软件设计的逻辑组织和意图，构件描述软件设计的物理实现

  构件可以部署，类不能部署。

  构件的种类

  配置构件：运行系统需要配置的构件

  工作产品构件：开发过程的产物

  执行构件：在运行时创建的构件

  表示

  

  Two interfaces:

  1. provided interface : 示出接口 构件实现的接口
  2. required interface : 引入接口 构件使用的接口

Component and Interface

在构件图中，构件可以通过其它构件的接口来使用其它构件中定义的操作

通过使用命名的接口，可以避免在系统中各个构件直接发生依赖关系，有利于构件的替换。

一般构件分为：

（1）执行文件：源码编译的结果，可直接运行。

（2）文件：信息存储体。

（3）库：类库，动态链接库，数据库

（4）表：数据库中的表

（5）文档：文字材料

构件图主要用于描述各种软件构件之间的依赖关系，例如，可执行文件和源文件之间的依赖关系。所设计的系统中的构件的表示法及这些构件之间的关系构成了构件图。

怎么画构件图?

1、确定划分的子系统的对外接口。程序子系统和系统外实际要进行联系的边界处理。

2、确定子构件和接口。在子系统中把功能不同的模块划分成构件，同时确定构件跟构件之间的接口。

3、确定构件之间的关系。分析构件之间存在的逻辑设计关系，画出依赖图。

Assembly connectors

Style of Component Diagram

1. Apply One Component Stereotype
   Consistently (始终使用一种表示方法)
2. Show Only Relevant Interfaces
3. Make Components Dependent Only on
   Interfaces

Deployment Diagram

Belong to Structure Diagram

• Deployment diagram are one of the two kinds of diagrams used in modeling the physical aspects of an object-oriented system. (Another is component diagram)
• We use deployment
  diagrams to visualize the static aspect of
  these physical nodes and their
  relationships and to specify their details
  for construction

Node

节点代表一个物理硬件，如一台Unix主机、
一个PC终端、一台打印机、一个传感器等，可以包含所配置的软件。

一般有两种类型：处理器和设备。

Graphically, a node is rendered as a
cube.

The most common kind of relationship used in nodes is an Association. Which represents a physical connection among nodes in this context.

连接是两个硬件节点之间的关联关系，表示节点之间的通信路径

连接用一条实线表示。连接硬件通常关心是如何连接的，因此一般不使用名称而使用版型来描述。

Differences between node and component

构件往往表示一个软件部件，节点往往表示一个硬件部件.

构件是参与系统执行的事物，节点是执行构件的事物.

构件表示逻辑元素的物理打包，节点表示构件的物理部署.

Application

设计阶段： 关注节点以及节点之间的连接

实现阶段： 关注如何将物理构件分配给节点。

Style

1. Use Descriptive Terms to Name Nodes
2. Model Only Vital Software Component
3. Apply Visual Stereotypes to Nodes
4. Indicate Communication Protocols via
   Stereotypes

Forward and Reverse Engineering

• Forward Engineering

• Given the UML model, generate the corresponding code

  UML Model -> Code

• Reverse Engineering

• Given the code for some classes, generate the corresponding model

  code -> UML Models

State Machine Diagram

Belong to Behavior Diagram

Concept

State

A state of an object is a period of time
during which it satisfies some condition,
performs some activity, or waits for some
event.

状态是指对象生命周期中的某个状况，在此期间对象将满足某些条件、执行某些活动或等待某些事件。

状态机图中不同的状态意味着对事件的不同反应方式。

Example of States

A player in a game may be in any of three states:

• Idle
• Walk
• Fight

Several Parts:

English	Chinese	Explanation
Name	名称	Distinguish from other states
Entry/Exit effects	进入/退出动作	Actions executed on entering or exiting the state
Internal transitions	内部转换	Transitions that are handled without causing a change in state
Substates	子状态	复合状态包含子状态
Deferred events	延迟事件	A list of states postponed and queued for handling by others.

Representation

We should represent a state as a rectangle with
rounded corners(圆角矩形)

State Machine

A state machine models the lifetime of a single
object, whether it is an instance of a class, a use
case, or even an entire system

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

Constituent Elements

• initial state

• 代表状态机图起始位置，只能作为转换的源，有且仅有一个 ，图如下：

  

• Final state

• 代表状态机图的终止点，只能作为转换目标，可以有多个，图如下：

  

• Transition

• 转换是两个状态(source state -> target state)之间的有向关系。

  外部转换被处触发时将引起状态变化，内部转换被触发时，不用离开并重新进入该状态，也不会调用进入/退出动作。

  语法：

  触发事件 Event trigger

  触发转换的内部或外部发生的事件。当源状态中的实体接收到事件后激活转换，在UML
  中，事件包括：Signals(信号),Calls(调用),the passing of time(时间) A change in state(改变)

  监护条件 Guard Condition

  A Boolean expression that must be true to trigger transition.

  动作Effect

  An effect is a behavior that is executed
  when a transition fires

  状态活动

  

• Choice Pseudo-State

  分支，在外部事件的作用下，根据监护条件的不同值，转向不同的目标状态。用空心菱形表示

  

• Composite state

  指状态机本身包含一个或多个状态机的状态，一般有两种:

  Concurrent (orthogonal)(顺序) or Sequential
  (nonorthogonal)(并发) Substates

  Examples:

  

  复合状态机

  复合状态可以包含一个或多个嵌套子状态机

  顺序复合状态恰好含有一个嵌套子状态机

  并发复合状态含有两个或多个并发执行的嵌套子状态机
  ​

  • 进入状态后存在分叉，子状态机开始并发执行
  • 如果所有子状态机都有一个终止状态，在所有子状态机结束之前不能离开超状态，称为结合
  • 如果子状态机显式地迁移到外部状态，那么离开超状态时就无须结合

• History State

  A history state is used to remember the
  previous state of a state machine when it
  was interrupted(离开).

  Representation:

  

  Example:

  

Application

Steps of State Machine Diagram
Modeling:

寻找主要状态

确定状态之间的转换

细化状态内的活动和转换

用复合状态展开细节

Pay attention:

Never Place a Guard on an Initial
Transition

Indicate Entry Actions Only When
Applicable to All Entry Transitions

Indicate Exit Actions Only When
Applicable to All Exit Transitions

Question:

• Question “Black-Hole” States

• 黑洞状态 : 有进无出

  A black-hole state is one that has transitions into it but
  none out of it, something that should be true only of
  final states.

  This is an indication that you have missed one or more
  transitions.

• Question “Miracle” States

• 神奇状态 : 有出无进

  A miracle state is one that has transitions out of it but
  none into it, something that should be true only of start
  points

  This is also an indication that you have missed one or
  more transitions

Question Collection

https://doc.weiyun.com/7b4420bf191976a417dd74c27ecfd79d

Part copied below:

UML Question Collections

For 18-19-2 UML Exam

遇到问题添加在这里，等待大佬回答

1.Q: 多重性是表示这个类一共有几个对象吗🙋‍

1.A: 应该是可以有几个对象？

感谢！

2.Q:What is the difference between UML and programming language？

一个是图一个是程序？//一个是建模语言、建立模型；另一个是编程语言，实现模型

2.A:The UML is a representation method, while the later one can generate an executable program?

3.Q: What’s RUP? Please talk about how you understand the RUP?

3.A: RUP is an iterative software development process framework, _________________?

RUP is an instantiation of UP

这样答就行了嘛？ 👆

4.Q: Use case analysis is a part of object oriented analysis and design? T or F?

4.A: T

5.Q: How to represent a collaboration ?

5.A: a collaboration is rendered as an ellipse with dashed lines

6.Q: What’s the relationship between Use cases and Collaborations?

6.A: In general, every use case should be realized by one or more collaborations 对吗?

7.Q: What’s the definition of scenario, and what’s the relationship between Use Cases and it?

7.A: A scenario is a specific sequence of actions that illustrates behavior, a scenario is basically one instance of a use case.

8.Q: What does the association with a single direction mean?

8.A: It could mean b posses a when a points to b like a->b.

9.Q: What’s the common problems in use case diagram?

9.A:

10.Q: what’s the common problems in class diagram?

10.A:

11.Q: ,what does this mean

11.A: It’s now <> not <> etc.

12.Q: How to comprehend association?

12.A: 是一种拥有的关系, 它使一个类知道另一个类的属性和方法

13.Q: What’s the difference between association names and association end names?

13.A:（1）左方对右方的关系/或者右方对左方[看箭头]（2）在此次关联中，左方扮演的角色，右方所扮演的角色（e.g）类company—-employer[end name]————————employs[association name]————————-employee—–类worker

[end names]

[association names]

14.Q: Three Stereotypes of class and their representation?

14.A:边界 控制 实体

15.Q: Three Perspectives of Class Diagram?

15.A: 概念层 说明层 实现层

16.Q: How to comprehend “Recursive or Reflexive Association”?

16.A:

17.Q: What’s the Principles of Object Oriented Class Design?

17.A: OCP, LSP, DIP, ISP

18.Q: The Main Phases Of The Software Life Cycle?

18.A: 需求分析 设计模型 编码 测试 维护

19.Q: The Main Phases of RUP?

19.A: 初启 细化 构造 移交

Reference

1. Sparxsystems UML2 Tutorial