Process models

  • 工作流模型--Workflow model
    • 流程模型显示了整个流程以及系统支持的流程
  • 数据流模型--Dataflow model
    • 数据流模型可用于显示流程以及从一个流程到另一个流程的信息流

Workflow model

Equipment procurement process

Data flow diagrams

  1. DFD 从功能角度对系统进行建模。
  2. 跟踪和记录与流程相关的数据如何有助于全面了解系统。
  3. 数据流图还可用于显示系统与其环境中的其他系统之间的数据交换。
Insulin pump DFD

Order processing DFD

Modeling using the Unified Modeling Language (UML)

UML Diagrams

Dynamic modeling

  • Use Case Diagrams 用例图
    • Use Case diagrams & descriptions
  • State Diagrams 状态图
    • State diagrams ---- State Machine
  • Interaction Diagrams 互动图
    • Sequence & collaboration diagrams

Static modeling

  • Implementation Diagrams
    • Package, Component & Deployment diagrams
  • Static Structure Diagrams
    • Class & object diagrams

Dynamic modeling

Use Case

用例(use case)指定了一个系统或系统的一部分的行为，是一组动作序列的描述，包括系统为给参与者带来可观察到的价值结果而执行的变量

参与者(actor)是与系统、子系统或类交互的外部人员、过程或事物的理想化。参与者描述外部用户与系统的交互

  • 用于描述系统中的主要流程以及流程（用例）(processes(use cases))与外部系统或称为参与者(actor)的个人之间的交互。
  • 一旦开发了概述，就可以将其扩展到包括子流程。
  • 用例描述是一个通用场景，是一系列描述参与者和用例之间交互的每个步骤的句子。

  • 用例(use case)在用例图中呈现为椭圆。用例总是标有其名称。

  • 在用例图中，参与者被呈现为一个棍状人物。每个参与者参与一个或多个用例。

  • 参与者可以参与与其他参与者的泛化(generalization)关系。

  • 参与者只能通过关联连接到用例。

State Machine

  • 对象在其生命周期中的任何给定时间都必须处于某种特定状态。
  • 对象从一种状态过渡到另一种状态是影响它的某个事件的结果。
  • 可以为UML模型中的任何类、协作、操作或用例创建状态图。
  • 状态图中只能有一个启动状态(start state)，但可能有许多中间和最终状态(final state)。

State Diagrams

状态机视图通过建模每个类对象的生命周期来描述对象随时间的动态行为。

每个对象都被视为一个孤立的实体，通过检测事件并对其作出响应来与世界其他地方进行通信。

事件表示对象可以检测到的各种变化，任何可以影响对象的东西都可以被描述为一个事件

  • 状态是一组值，用于描述某一时刻的对象。
  • 状态图提供了一个对象在接收连续消息时发生的情况的精确视图。
  • 并非每个类都需要有状态图——只有当它们是非常动态的时，它才有助于理解对象的所有可能状态，并且当消息触发从一个状态到另一个状态的每次转换时。

例子

Sequence Diagram

序列图是强调消息时间顺序的交互图。它显示一组对象以及这些对象发送和接收的消息。

从图形上看，序列图是一个表格，显示沿X轴排列的对象和沿Y轴按时间递增排序的消息。

  • 以图形方式演示场景
  • 它们显示对象相互传递消息的顺序
  • 消息：请求对象执行方法（调用方法）
  • 它们显示创建和销毁对象的时间
objects 对象

序列图中的对象呈现为一个框，框中有一条从框中向下的虚线。

这条线被称为对象生命线，它表示对象在一段时间内的存在。

Message 消息
  • 消息呈现为水平箭头，随着时间沿着对象生命线向下移动，从一个对象传递到另一个对象。
  • 条件（如[check=“true”]）指示消息何时传递。

最后的箭头表示从上一条消息返回，而不是新消息。

iteration marker 迭代标记

迭代标记，例如*（如图所示）或*[i=1..n]，指示消息将按指示重复。

例子

Collaboration Diagram

  • 协作图强调参与交互的对象之间的关系。

  • 与序列图不同，您不必在协作图中明确显示对象的时间线。

  • 事件序列由消息前面的序列号指示。

  • 对象标识符的形式为 objectName : className，并且可以省略 objectName 或 className，并且冒号的位置表示 objectName: 或 :className。

  • 提供显示事件发生顺序的第二种方式

  • 对象显示在由指示它们之间的链接的线连接的矩形中。

  • 数字表示操作的执行顺序。

  • 数字与消息名称和指示流向的箭头一起书写。

  • 协作图和序列图都源自 UML 元模型中的相同信息，因此您可以采用一种形式的图并将其转换为另一种形式。
  • 它们在语义上是等价的。

Activity Diagram

  • 活动图本质上是一个流程图，显示了从活动到活动的控制流。
  • 使用活动图来指定、构建和记录对象社会的动态，或对操作的控制流进行建模。
  • 交互图强调从对象到对象的控制流，而活动图则强调从活动到活动的控制流。
  • 活动是状态机内正在进行的非原子执行。

Static Modeling

Classes 类

  • 类是对共享相同属性、操作、关系和语义的一组对象的描述。

  • 在图形上，一个类被呈现为一个矩形，通常在单独的、指定的隔间中包含它的名称、属性和操作。

Class Names

类的名称是类的图形表示中唯一必需的标记。 它总是出现在最上面的隔间中。

Class Attributes

  • 属性是一个类的命名属性，用于描述被建模的对象。

  • 在类图中，属性出现在名称隔间正下方的第二个隔间中。

  • 属性通常以以下形式列出：

    • 属性名称：类型

  • 派生属性是可以从其他属性计算出来的属性，但实际上并不存在。

    • 例如，一个人的年龄可以从他的出生日期计算出来。
    • 派生属性由前面的“/”指定，如下所示：/ 年龄：日期
    • +public
    • #protected
    • -private
    • /derived

Class Operations

  • 操作描述类行为
  • 并出现在第三个隔间。

您可以通过声明其签名来指定操作：列出所有参数的名称、类型和默认值，如果是函数，则列出返回类型。

绘制类时，不必在每个图中都显示属性和操作。

Class Responsibilities

  • 一个类也可以在类图中包含它的职责。

  • 责任是类执行特定服务的合同或义务。

Relationships

  • 在 UML 中，对象互连（逻辑或物理）建模为关系。

  • UML中存在三种关系：

    • 依赖 -- dependencies

    • 泛化 -- generalizations

    • 关联 -- associations

Dependency Relationships 依赖关系
  • 依赖项表示两个或多个元素之间的语义关系。
  • 从 CourseSchedule 到 Course 的依赖存在是因为 Course 被用于 CourseSchedule 的添加和删除操作。

Generalization Relationships 泛化关系
  • 类似于继承关系
  • 泛化将子类与其超类连接起来。
  • 它表示从超类到子类的属性和行为的继承，并表示在更一般的超类的子类中的特化。

  • UML 允许一个类从多个超类继承，尽管一些编程语言（例如 Java）不允许多重继承。

Association Relationships 关联关系

  • 如果模型中的两个类需要相互通信，则它们之间必须存在链接。

  • 关联表示该链接。

  • 我们可以通过向表示关联的行添加多重装饰来指示关联的多重性。

该示例表明学生有一个或多个讲师：

该示例表明每个教师都有一个或多个学生：

我们还可以使用角色名称指示关联中对象的行为（即对象的角色）。

为关系命名

我们可以指定双重联系。

  • 我们可以通过定义关联的可导航性(navigability)来约束关联关系。

    在这里，路由器对象通过向服务器（调用其操作）发送消息来从 DNS 对象请求服务。 关联的方向表明服务器不知道路由器。

  • 关联也可以是对象本身，称为链接类(link classes)或关联类(association classes)。

  • 一个类可以有一个自关联。

  • 我们可以通过称为聚合(aggregations)和组合(compositions)的特殊关联对包含其他对象的对象进行建模。

  • 聚合指定了聚合（整体）和组成部分之间的整体-部分关系，其中该部分可以独立于聚合而存在。 聚合由关联上的空心菱形装饰表示。

  • 组合表示整体对部分的所有权和重合的生命周期（即，它们作为一个整体存在和消亡）。 组合由关联上的填充菱形装饰表示。

Interfaces

  • 接口是一组命名的操作，它指定对象的行为而不显示它们的内部结构。
  • 它可以通过一个或两个隔间的矩形在模型中呈现，接口名称上方带有构造型 。

Interface Services
  • 接口不会被实例化。
  • 它们没有属性或状态。
  • 相反，它们指定了相关类提供的服务。

Interface Realization Relationship
  • 实现关系将类与提供其行为规范的接口连接起来。
  • 它由一条带有空心三角形的虚线呈现，指向说明符。

Enumeration

枚举是一种用户定义的数据类型，由名称和枚举文字的有序列表组成。

Exception

  • 可以像任何其他类一样建模。

  • 注意名称隔间中的构造型。

Package Diagrams

  • 包是将定义的类组织成组。
  • 它们代表逻辑软件模块。
  • 它们使用与类图相同的关联（聚合、关联、泛化/特化、依赖……）
    • (aggregation, association, generalization/specialization, dependency,…)

Packages
  • 包是一种类似容器的元素，用于将其他元素组织成组。
  • 一个包可以包含类和其他包和图表。
  • 包可用于在不同包中的类之间提供受控访问。

  • 在此图中，FrontEnd 包中的类和BackEnd 包中的类不能相互访问。

  • BackEnd 包中的类现在可以访问 FrontEnd 包中的类。

  • 我们可以对包之间的泛化和依赖关系建模。

Component Diagram

  • 组件图是在面向对象系统的物理方面建模时发现的两种图之一。

  • 它们显示了一组组件之间的组织和依赖关系。

  • 使用组件图对系统的静态实现视图进行建模。

  • 这涉及对驻留在节点上的物理事物进行建模，例如可执行文件、库、表、文件和文档。

  • 组件是任何形式的软件

  • 组件图显示软件组件及其关系（虚线箭头）

  • 它们从高级视图显示物理组件，以显示代码模块是如何分布的。

  • 它们更常与部署图(deploymend diagrams )一起使用，而不是分开使用。

example

Deployment Diagram

  • 部署图是在面向对象系统的物理方面建模时发现的两种图之一。

  • 它们显示了运行时处理节点的配置以及它们上的组件。

  • 使用部署图为系统的静态部署视图建模。 这涉及对系统执行的硬件拓扑进行建模。

  • 每个节点或处理元素都由一个 3D 框表示。

  • 通信/关系用实线表示

  • 组件是具有明确定义的接口的物理实现单元，旨在用作系统的可替换部分。
  • 设计良好的组件不直接依赖于其他组件，而是依赖于组件支持的接口。