软件工程与过程第五课 PPT

L5_CS335_Sys_Modelling.pdf

目标 (Objectives)

  • 理解系统建模的必要性。
  • 掌握系统建模的基本视角：
    • 上下文模型 (Context models)
    • 交互模型 (Interaction models)
    • 结构模型 (Structure models)
    • 行为模型 (Behaviour models)
  • 理解统一建模语言 (UML) 中的主要图表类型。
  • 应用UML进行系统建模实践。

模型 (Model) 是什么？

  • 图形表示法 (Graphical Representation): (例: UML 类图 <网络监视器>)
  • 数学表示法 (Mathematical Representation): (例: Z 形式化规约 <继承部分>)

“模型是所研究系统的抽象化。”
-- Sommerville, I., 2011. 软件工程第9版。

“模型是从特定视角对规约、设计或系统的抽象表示。”
-- Stevens, P. and Pooley, R., 1999. 使用 UML：面向对象和组件的软件工程。

构建模型的目的 (The Purposes of Building Models)

  • 针对现有系统 (For an Existing System):
    • 辅助阐明现有系统的功能。
    • 促进关于系统优势与劣势的讨论。
  • 针对新系统 (For a New System):
    • 辅助解释提议的需求规格。
    • 促进关于设计方案的讨论。
    • 辅助为系统实现编写文档。
  • (流程示意: 需求工程 (Requirements Engineering) -> 文档化 (Documentation) -> 设计过程 (Design Process))
  • 系统模型并非系统的完整表示，而是系统的一种替代性表述。

系统建模视角 (System Modelling Perspectives)

  • 外部视角 (External):
    • 关注系统的上下文或环境。
    • 例: 系统是否使用了第三方API进行信用卡认证？导航应用是否依赖谷歌地图服务？
  • 交互视角 (Interaction):
    • 关注系统与其环境/用户之间，或系统组件之间的交互。
    • 例: 用户如何与系统交互？项目中移动客户端如何与云后端交互？
  • 结构视角 (Structural):
    • 关注系统的组织结构或系统处理的数据结构。
    • 例: 如何将源代码组织成不同的包 (packages)？
  • 行为视角 (Behavioral):
    • 关注系统的运行时行为及其对事件的响应机制。
    • 例: 若系统接收到非预期的消息，会发生什么情况？

“系统建模是开发系统抽象模型的过程，其中每个模型呈现该系统的不同视图或视角。”
-- Sommerville, I., 2011. 软件工程第9版。

统一建模语言 (Unified Modeling Language - UML)

  • 旨在标准化软件设计的符号体系，于1994-1996年设计和开发。
  • 自1997年起由对象管理组织 (Object Management Group - OMG) 采纳并管理。
  • (图示：建模语言发展史及UML版本时间轴)

UML 图表 (UML Diagrams)

  • UML 2.5 图表分类:
    • 结构图 (Structure Diagrams):
      • 类图 (Class Diagram)
      • 对象图 (Object Diagram)
      • 包图 (Package Diagram)
      • 组件图 (Component Diagram)
      • 部署图 (Deployment Diagram)
      • 复合结构图 (Composite Structure Diagram)
      • Profile图 (Profile Diagram)
    • 行为图 (Behavior Diagrams):
      • 用例图 (Use Case Diagram)
      • 活动图 (Activity Diagram)
      • 状态机图 (State Machine Diagram)
      • 交互图 (Interaction Diagrams - 行为图的子类):
        • 顺序图 (Sequence Diagram)
        • 通信图 (Communication Diagram)
        • 交互概览图 (Interaction Overview Diagram)
        • 时序图 (Timing Diagram)
  • 来源: UML Diagrams: Object Management Group. OMG Unified Modeling Language (UML), Superstructure. Technical Report Version 2.5.1, OMG, 2017.

UML 工具 (UML Tools)

  • (列举工具图标: ArgoUML, StarUML, Borland Together)
  • (展示UML模型的XML元数据交换 (XMI) 格式代码片段)

系统建模 – 外部视角 (System Modelling – External Perspective)

  • 上下文模型 (Context Model):
    • 在需求工程的早期阶段创建。
    • 旨在明确待开发系统的边界。
    • 建立系统与其操作环境之间交互的高层视图，不含细节。
    • 通常使用简单的框图或空类图表示。
    • 注意: UML并未提供专门用于上下文模型的图表类型。
  • 业务过程模型 (Business Process Model):
    • 用于对业务流程进行建模。
    • 描绘系统如何参与特定的业务过程。
    • 可使用活动图或专用的业务过程模型和符号 (BPMN)。
    • BPMN是业务过程建模的标准，提供类似UML的图形符号来表达业务过程。(参考: https://www.omg.org/spec/BPMN/2.0/)
  • (右侧示意图高亮“外部视角”)

上下文建模 vs. 业务过程建模 (Context Modeling vs. Business Process Modeling)

  • 上下文建模与业务过程建模均为业务分析和系统设计领域的重要概念，但用途不同。
  • 上下文建模 (Context Modeling):
    • 定义: 关注理解系统运行的环境或背景，涉及识别利益相关者、其角色、交互、约束及可能影响系统的外部因素。
    • 目的: 提供系统环境的整体视图，帮助设计者和利益相关者更好地理解系统范围和需求，定义边界，识别对外部实体的依赖。
    • 技术: 可包括利益相关者分析、用例建模、场景分析和环境分析。
  • 业务过程建模 (Business Process Modeling):
    • 定义: 涉及表示组织内部为达成特定业务目标而发生的一系列活动、任务、决策和交互，旨在捕获业务操作的结构和流程。
    • 目的: 提高效率、优化操作、促进组织内部沟通和理解，帮助识别瓶颈、冗余和改进点。
    • 技术: 可包括流程图、BPMN、UML活动图和过程映射。
  • 关键差异 (Key Differences):
    • 范围 (Scope): 上下文建模关注系统周边的广阔环境和利益相关者；业务过程建模聚焦组织内部操作和工作流。
    • 焦点 (Focus): 上下文建模强调理解系统运行的上下文（含外部影响和交互）；业务过程建模关注组织内部的具体活动和过程。
    • 产出 (Outcome): 上下文建模产出对系统环境和利益相关者的全面理解；业务过程建模产出组织工作流和操作的可视化表示。
  • 总结: 两者对系统设计和分析都至关重要，但服务于不同目的，解决系统及其环境的不同方面问题。

上下文模型示例 (Context Model Example: MentCare)

  • 上下文模型图元素:
    • 系统或外部系统 (System or external system)
    • 系统与外部系统间的连接 (Connection between the system and external systems)
  • 项目描述: 中苏格兰地区卫生局欲采购一套信息系统，用于辅助管理精神疾病患者的护理。系统总体目标有二：
    1. 为该地区的精神医疗保健提供更优的管理信息。
    2. 为参与诊断和治疗的临床人员提供改进的记录系统。
  • (图示：MentCare管理系统 (<<system>> MentCare Mgmt System) 与 患者记录系统 (<<system>> Patient Record System), 管理报告系统 (<<system>> Mgmt Report System), 处方系统 (<<system>> Prescription System) 等多个外部系统交互)
  • 来源: Sommerville, I., 2011. 软件工程第9版

练习：上下文模型 (Exercise: Context Model - CTS)

  • CTS 信息系统 (City Transport Service - CTS)
  • 项目描述: 城市旅游信息办公室希望为外国游客提供在线城市交通服务。该服务是一个信息系统，允许用户规划行程、预订城市铁路和公交服务的车票。
  • (图示：CTS系统与 行程规划 (Journey Planning), 车票预订 (Ticket Booking), 在线支付服务 (Online Payment Service), 交通部 (Department of Transport), 身份验证服务 (ID Verification Service), 认证与注册服务 (Authentication & Registration Service) 的交互)

术语：构造型 (Terminology: Stereotype)

  • (图示重复MentCare上下文模型，每个系统使用 <<system>> 构造型)
  • 用于描述模型元素。
  • 放置在图表中靠近元素的位置。
  • 使用一对尖括号 << >> 包裹类型名，例如 <<use>>, <<include>>, <<import>>, <<system>> 等。

”构造型是UML为模型项附加额外分类的方式；它是UML实现可扩展性的途径之一。”
-- Stevens, P. and Pooley, R.J., 2006. Using UML: software engineering with objects and components. Pearson Education.

活动图的元素 (Elements of Activity Diagram)

“活动 (Activity) 是一种行为 (Behavior)，它被指定为由边 (edges) 互连的节点 (nodes) 图。执行流被建模为由活动边 (ActivityEdges) 连接的活动节点 (ActivityNodes)。”
-- OMG, O., 2017. OMG Unified Modeling Language (OMG UML) Version 2.5.1.

  • 活动节点 (ActivityNodes):
    • 动作/可执行节点 (Action/Executable Node): 执行预期的行为。
    • 对象节点 (Object Node): 持有对象令牌 (object tokens)。
  • 边 (Edges):
    • 活动边 (Activity edge)
    • 可中断区域活动边 (Activity edge for interruptible regions)
  • 控制节点 (Control Nodes): 管理动作流。
    • 合并/分叉 (join/fork)
    • 判断/汇合 (decision/merge)
    • 初始节点 (initial node)
    • 流终止节点 (flow final)
    • 活动终止节点 (final node)
  • 注: 此处未展示许多其他高级符号。

使用活动图进行业务过程建模 (Business Process Modelling using Activity Diagrams)

  • (包含一个示例活动图)
  • 初始节点 (Initial Node): 代表活动执行起点的控制节点。
  • 活动终止节点 (Final Node): 活动中行为停止处的控制节点。
  • 分叉节点 (Fork Node): 将一个流拆分为多个并发流的控制节点。
  • 合并节点 (Join Node): 同步多个流的控制节点。
  • 汇合节点 (Merge Node): 将多个流汇集在一起（无需同步）的控制节点。
  • 判断节点 (Decision Node): 在多个传出流之间进行选择的控制节点。
  • 对象节点 (Object Node): 持有对象令牌，例如工件 (artifacts)、系统、数据或字符串等。

系统建模 – 交互视角 (System Modelling – Interaction Perspective)

  • 用户交互 (User interaction): 涉及用户输入和输出；有助于识别用户需求。
  • 系统交互 (System interaction): 待开发软件系统与其环境中的系统之间的交互；突显可能出现的通信问题。
  • 组件交互 (Component interaction): 软件系统组件之间的交互；有助于理解提议的系统结构是否能满足所需的系统性能和可靠性。
  • (右侧示意图高亮“交互视角”)

用例 (Use Cases)

  • 识别系统与外部行动者 (actors) 之间的交互，行动者可以是：
    • 人类用户
    • 其他系统
  • 识别交互中涉及的行动者，并命名交互类型。
  • 每个用例代表一个涉及与系统外部交互的离散任务。
  • 可通过高层用例图或对用户期望从系统中获得功能的简单描述进行文档化。
  • 示例: 用户故事索引卡管理系统：更新用户故事
    • 行动者 (Actors): 产品负责人 (Product Owner)
    • 描述 (Description): 产品负责人可修改系统中已有的用户故事。修改时，更新的信息必须经过验证（例如，Sprint点数必须为数值）。同时，所有必填字段须填写完整，然后保存到持久存储。更新后的用户故事必须立即对用户可见。
    • 数据 (Data): 系统中已有的用户故事。
    • 触发器 (Stimulus): 产品负责人发出的用户命令。
    • 响应 (Response): 确认用户故事已验证、更新并保存。
    • 注释 (Comments): 执行修改操作的人必须先以产品负责人角色登录；项目文件必须已在系统中加载。

使用 UML 进行用例建模 (Use Case Modeling Using UML)

  • 用例图元素:
    • 系统边界 (System boundary): (使用 <<system>>, <<subsystem>> 或 <<subject>> 构造型)
    • 行动者 (Actor)
    • 用例 (Use Case)
    • 关联 (Connection / Association)
  • (图示：基于前页描述绘制用例图，包含 ProductOwner 行动者与系统边界内的 Update User Story, Login, Validate User Story, Check Completion, Save User Story, Refresh Display 等用例)

用例依赖 -- 扩展 (Use Case Dependency -- Extends)

  • (图示与前页类似)
  • 扩展关系 (<<extend>>) 的使用场景:
    1. 当存在一些需要（可能是有条件地）添加的附加行为时。
    2. 被扩展用例 (Extended UseCase - Target) 的定义独立于扩展用例 (Extending UseCase - Source/Extension)。
    3. 扩展用例本身可能没有独立意义。
  • (图中用例关系未明确标注为 Extend，但标题表明此页讨论 Extend 关系)

用例依赖 -- 包含 (Use Case Dependency -- Include)

  • (图示与前页类似，但用例间关系使用虚线箭头和 <<include>> 构造型)
  • 包含关系 (<<include>>) 的使用场景:
    1. 包含用例 (Including UseCase - Source) 可能依赖于执行被包含用例 (Included UseCase - Target) 所产生的变更。
    2. 被包含用例必须可用，包含用例的行为才能得以完成。
    3. 当两个或多个用例的行为存在公共部分时，也可使用此关系。
  • (示例图显示 Update User Story <<include>> 了 Validate User Story, Save User Story, Refresh Display, Check Completion)

用例头脑风暴 – 火车票在线预订系统 (Use Case Brainstorming – Train Ticket Online Booking System)

  • (图示包含多个行动者和用例)
  • 行动者: 客户 (Customer), 网站管理员 (Site Admin), 客户服务 (Customer Service), 在线支付系统 (Online Payment System), 经理 (Manager)
  • 用例: 选择行程 (Choose Journey), 选择座位 (Select Seat), 选择附加服务 (Pick Extra), 登录 (login), 查看预订 (Review Booking), 付款 (Make Payment), 退款 (Refund), 注册 (Register), 更新网站 (Update Site), 收集报告 (Collect Report), 取消预订 (Cancel Booking)

用例依赖 -- 泛化 (Use Case Dependency -- Generalization)

  • (图示展示行动者之间的泛化关系)
  • 泛化 (Generalization) ≈ “是一种” (is a)
  • (示例图显示 Staff 是 Site Admin, Customer Service, Manager 的父类/泛化)

交互建模 (Interaction Modelling)

  • 交互概览图 (Interaction Overview Diagram): 通过活动图的变体定义交互；侧重于控制流的概览。
  • 通信图 (Communication Diagram): 侧重于内部结构实体间的交互及其与消息流的对应关系。
  • 顺序图 (Sequence Diagram): 描述多个生命线 (lifelines) 之间消息交换的方式；顺序图和通信图的功能大体相同。

顺序图 (Sequence Diagrams)

  • (图示展示顺序图的基本元素)
  • 元素:
    • 生命线 (:Lifeline): 代表交互中的单个参与者或对象。
    • 交互框 (Frame for Interaction sd): 包裹整个交互。
    • 同步消息 (Synchronous Message): 调用者等待响应的消息。
    • 异步消息 (Asynchronous Message): 调用者不等待响应的消息。
    • 回复消息 (Response Message): 对同步消息的响应。
    • 执行规约 (Execution Specification): 表示生命线处于活动状态的时间段（处理消息）。
    • 找到的消息 (Found Message): 接收者已知，但发送者未在图中明确表示的消息。
    • 丢失的消息 (Lost Message): 发送者已知，但接收者未在图中明确表示的消息。
    • 创建消息 (Create Message): 表示生命线的实例化。
    • 销毁事件 (Destruction Occurrence): 表示生命线的终止。
    • 抉择组合片段 (Alternative Combined Fragment - alt): 表示基于条件选择不同的交互路径。
    • 事件发生规约 (Event Occurrence Specification): 标记生命线上消息发送或接收的特定点。

示例：用户故事索引卡管理系统 -- 登录 (Example: User Story Index Card Management System -- Login)

  • (包含登录过程的顺序图示例，涉及 Actor, LoginPage, UserSession, UserFileDB 等生命线)
  • 生命线 (Lifeline): 代表交互中的单个参与者或对象。
  • 找到的消息 (Found Message): 接收者已知，但发送者未在规约中描述的消息。
  • 同步消息 (Synchronous messages): (或调用) 带有回复。
  • 创建消息 (Create message): 代表生命线的实例化。
  • 递归消息 (Recursive Message): 代表同一生命线调用自身消息。

系统建模 – 结构视角 (System Modelling – Structural Perspective)

  • 对系统在功能组件及其关系方面的组织结构进行建模。
  • 模拟系统设计的静态结构 (static structure)。
  • 模拟系统执行时的动态结构 (dynamic structure)。
  • 用于讨论和设计系统架构。
  • 类图 (Class diagrams) 用于对系统的静态结构进行建模。
  • (右侧示意图高亮“结构视角”)

类图 (Class Diagram)

  • (图示展示类图基本元素和关系)
  • 核心元素:
    • 类 (Class): 包含类名 (ClassName)、属性 (attributes)、操作 (operations)。
    • 抽象类 (Abstract Class): 类名和操作通常用斜体表示，不能直接实例化。
    • 接口 (Interface): 使用 <<Interface>> 构造型，定义一组操作契约。
  • 主要关系:
    • 泛化 (Generalization): "is-a" 关系，表示继承。
    • 关联 (Association): 表示类之间的结构化连接。
    • 依赖 (Dependency): 表示一个类使用另一个类。
    • 实现 (Realization): 表示类实现接口。
    • 组合 (Composition): 强"whole-part"关系，部分生命周期依赖整体。
    • 聚合 (Aggregation): 弱"whole-part"关系，部分生命周期独立于整体。

泛化 (Generalization)

  • 泛化表示 “is-a” 关系（继承）。此例中，可解读为经理 (Manager) 是一种用户 (User)；开发者 (Developer) 是一种用户。子类（Manager 和 Developer）自动继承父类的属性和操作。例如，Manager 也拥有 name 和 role 属性。
  • (图示: User 类作为父类，Manager 和 Developer 作为子类继承 User)
  • 类可包含多个属性 (attributes / properties) 和操作 (operations / methods)。
  • 属性可见性可以是 private (-), protected (#), public (+) 或 package/default (~)。
  • 类可包含零个或多个操作。为允许其他类访问私有属性，常提供公共的 ‘getters’ 和 ‘setters’ 操作。

泛化 -- UML 到代码 (Generalization -- UML to Code)

  • (展示与前页 UML 图对应的 Java 代码片段：Role 枚举, User 类, Manager 类继承 User 类)

依赖 (Dependency)

  • 依赖表示实体间的一种关系，其中一个实体（客户端）定义的变化可能导致另一个实体（供应端）的变化。
  • 常用构造型表示不同类型的依赖，如 <<use>>, <<import>>, <<depend>>, <<refine>>, <<extend>>, <<include>>, <<access>>, <<instanceOf>>, <<bind>>, <<instantiate>> 等。
  • (示例图显示 UserFileDB 依赖于 User 和 Role 类，以及 Java 标准库中的 File, FileNotFoundException, Scanner)
  • 可以是导入 (<>) 标准 Java 库。
  • 可以是导入 (<>) 同一程序中不同包的类。

依赖 – UML 到代码 (Dependency – UML to Code)

  • (展示 UserFileDB 类的 Java 代码片段，import 语句体现了对 File, Scanner, Role, User 的依赖关系)

实现 (Realization)

  • 在实现关系中，类（实现类）承诺履行接口所定义的操作契约。
  • 接口使用 <<interface>> 构造型定义。实现关系用虚线空心箭头表示。
  • (示例图显示 FileDBOperator 和 MySQLDBOperator 类实现了 DBOperator 接口)
  • (包含 DBOperator 接口, FileDBOperator 类, MySQLDBOperator 类的 Java 代码片段)

关联 (Association), 聚合 (Aggregation) 和 组合 (Composition)

  • 关联 (Association): 表示系统中对象之间的结构化连接或关系。是最泛化的连接。
  • 聚合 (Aggregation): 关联的子类型，表示 ‘部分-整体’ (part-of) 关系。在聚合中，部分对象拥有独立的生命周期（空心菱形）。
  • 组合 (Composition): 聚合的子类型，表示更强的 ‘整体/部分’ (whole/part) 关系。如果整体被销毁，其组成部分也将随之销毁（实心菱形）。
  • 关系强度: 组合 ⊂ 聚合 ⊂ 关联
  • (包含示例图展示这三种关系)

包图 (Package Diagrams)

  • 包 (Package) 被视为其成员的命名空间 (namespace)。
  • 在分析阶段，包图用于组织开发过程中的工件 (artifacts)。
  • 提供封装 (encapsulation) 和包含 (containment)，支持模块化 (modularity)。
  • 在复杂系统开发中提供清晰度和整洁的组织结构。
  • 支持版本控制。
  • 关系: 依赖 (Dependency), 包含 (Containment)

包图示例 (Package Diagram Examples)

  • (展示两个包图示例，演示包的嵌套和依赖关系)
  • 或者 (OR)
  • 包是其成员的命名空间，成员包括其拥有或包含的元素以及导入的元素。

部署图 (Deployment Diagrams)

  • 部署图展示系统逻辑和/或物理元素与分配给它们的资产 (assets) 之间的关系。
  • 元素:
    • 节点 (Node): 表示硬件设备或软件执行环境。
    • 工件 (Artifact): 表示物理存在的具体元素（如文件、库、可执行文件）。
    • 通信路径 (Communication Path): 表示节点间的通信连接。
    • 依赖 (Dependency): 表示一个元素依赖于另一个元素。
    • 部署关系 (<<deploy>>): 表示工件部署到节点上。

部署图用例 (Deployment Diagram Use Case)

  • (包含一个部署图示例)
  • 工件 (Artifact): 代表物理世界中由软件开发过程或系统操作使用或产生的具体元素。例如：可执行文件、源文件、数据库表、文档或消息等。
  • 节点 (Node): 通用元素，可代表硬件设备或软件执行环境。
  • 设备 (Device): 节点的子类型。用于表示具有处理能力的物理计算资源，工件可部署其上执行。
  • 执行环境 (ExecutionEnvironment): 节点的子类型。用于表示支持工件执行的某种环境（通常是软件）。通常分配给设备或节点。例如：应用服务器、操作系统或数据库等。
  • 通信路径 (CommunicationPath): 两个部署目标（节点）之间的一种关联，它们可通过该路径交换信息。
  • 部署规约 (Deployment Specification): 指定部署在节点上的工件的一组属性。
  • (示例图标注了 HTTP: 超文本传输协议)

总结 (Summary)

  • 模型是系统的抽象视图，有意忽略某些系统细节。
  • 上下文模型展示系统在操作环境中的定位，有助于定义系统边界。
  • 用例图用于描述外部行动者与待开发系统之间的交互。
  • 顺序图用于展示系统对象之间的交互序列。
  • 类图用于定义系统类的静态结构及其关系。
  • 包图用于组织开发过程中的工件。
  • 部署图用于展示组件到物理节点的分配。

练习 (Practice)

练习 1

在面向对象设计中，建模实体间的复杂关系颇具挑战。以下类图使用继承对生物进行建模。该模型技术上正确，但逻辑上存在谬误：蝙蝠是哺乳动物却能飞，企鹅是鸟类却不能飞。请使用类组合 (class composition) 重新设计该类图，使其在逻辑和技术上均正确无误。
(包含一个逻辑错误的继承类图示例: Creature -> Bird, Mammal; Bird -> Penguin; Mammal -> Bat)

练习 2

根据以下代码片段，绘制对应的类图：
(提供 cn.fzu.miec.doc.Report, cn.fzu.miec.device.Printer, cn.fzu.miec.device.HPPrinter 三个类的 Java 代码)

练习 3

* 开发一个顺序图，展示学生在大学注册课程时所涉及的交互过程。课程可能有选课人数限制，因此注册过程必须包含检查名额是否可用的步骤。假定学生通过访问电子课程目录来了解可选课程。

posted @ 2025-05-05 10:47  糖子哥  阅读(43)  评论(0)    收藏  举报