uml建模技术

基础篇——在学习中思考！ 在大概了解了 UML 之后就该系统的学习 UML 的主要建模元素了，一个个实例帮助我们更好的理解这些元素的重要性并运用相关知识解决实际问题。 在 UML 里有一个概念叫版型，有些书里也称为类型、构造型。版型只是 UML 的一种扩展手段，本身并不涉及太多的思想和方法，而是在建模的不同阶段，为了区分视图之间的不同观点，会采用不同的图示来表示。 以人为本是当代的流行词汇， UML 建模也是以人为本的。参与者在建模过程中是处于核心地位的， actor 是在系统之外与子同交互的某人或某事。系统之外的定义说明在参与者和系统之间有一个明确的边界，赞誉这只可能存在于边界之外，边界之内的人和事物都不是参与者。在查找参与者的过程中，可以询问以下问题以帮助确定参与者： （1）谁是负责提供、使用或删除信息？ （2）谁将使用此功能？ （3）谁对某个特定的功能感兴趣？ （4）在组织的什么地方使用系统？ （5）谁负责支持和维护系统？ （6）系统有哪些外部资源？ （7）其他还有那些系统需要与该系统交互？ 查找参与者时请注意，参与者一定是直接并且主动的向系统发出动作并获得反馈的，否则就不是参与者。此时可以理解刚开始举的例子“小王到银行去开户，向大厅经历询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折。”在这个场景中，小王是参与者，而经理和柜台职员及其他事物都在系统边界以内

面向对象的特征 *P9* >封装性 >继承性 >多态性 >传递性 建模语言的三个类别 *P14* > - 非形式化的、半形式化的和形式化的 UML 特点*15* 主要有三个特点： >- 1. 统一了Booch、OMT和OOSE等基本概念 >- 2.UML吸取了面向对象技术的优点，当然也有非面向对象技术的影响 > - UML 还提出了许多新说法，增加了模板、职责、扩展机制、线程、过程、分布式、并发、模式、协作、活动等概念，并清晰的区分类型、类和实例、细化、接口和组件等概念。 RUP的三大特点*P28* >- 降低了一个增量上的开支风险。 >- 降低了产品无法按照既定进度进入市场的风险。 >- 加快了整个开发工作的进度。 RUP的开发过程*P30* >- 初始阶段 >- 细化阶段 >- 构造阶段 >- 交付阶段 基数表*P49* 略 需求获取的方法 *P64* >- 1、现场调查 >- 2、网络调查 >- 3、复杂网络和数据挖掘 需求分析的目的 （确定客户需要什么）*P75* >- 用来明确问题需求 >- 为用户和开发人员提供明确需求 >-为用户和开发人员提供一个协商的基础，作为后续的设计和实现的框架 RUP设计过程图*P89* >- >- 见书图9_1 登录UI界面 >- >- P89书图 UML模型划分（静态、动态） >- >- 书P16图 来源： https://www

一：基本信息 标题：基于 UML 技术的体育场馆管理系统设计与研究 时间：2017 出版源：西安航空职业技术学院 文件分类：文献笔记 二：研究背景 由于目前体育场馆人员、 设施以及运动项目不断呈现多样化发展需求[1]，使得体育场馆管理的复杂度也不断提升，亟待优化设计体育场馆管理系统，才可满足实际需求。运用 UML 技术，优化设计体育场馆管理系统，发挥积极影响。 问题定义：体育场馆管理系统设计与研究 难点：应用 B/S 模式优化设计体育场馆管理系统结构，以确保设计的系统满足实际应用需求。 相关工作：1：介绍UML技术的优缺点 2：进行系统的需求分析 3：进行优化设计体育场馆管理系统 4：进行该系统设计应用效益的分析 三：具体内容 系统总体结构： 系统 UML 建模 系统软件代码实现： public abstract class Persistent {private int objid； private static RandomAccessFile iterfile； public Persistent（） {String cname = getClass（）.getName（）； try { RandomAccessFile file = new RandomAccessFile（cname + ".dat"，"rw"）； try{ // Update object id

用例图介绍 用例图(Use-Case Diagram),是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图可以直观呈现系统与功能模块之间的互动关系，便于软件设计初期的建模。借助于用例图，开发相关人员，客户与专业人士能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。 用例图关键要素 参与者 参与者是指独立于系统，并与系统存在交互的对象，可以是人，物体，其他系统等等。 系统边界 设计系统，需要明确系统边界，知道哪些是系统内部的东西，哪些是系统外部的东西，方便后期的统一设计规划。 用例 系统里面的功能，模块或者属性，行为等。 关系 参与者与用例的关系，参与者与参与者的关系 关系的介绍 不同的关系用不同的线条来表示，以下是主要关系。 包含(include) 比如管理学生信息，包含增添学生信息，修改学生信息，删除学生信息，一般是对行为与功能的进一步细化，细化的程度需要掌握好，不然设计的用例图效果不好。 扩展(extend) 例如，查询操作可以对结果进行导出、打印。对于查询而言，能不能导出、打印，查询都是一样的，它们不是必须做的操作。扩展一般是行为与功能的一些可选，非必须的细化操作。 泛化(generalization) 比如车和公交车，是一种继承泛化的关系。 关联(Association)

统一建模语言(UML)已经迅速变成建立面向对象软件的事实标准。本教程提供了Enterprise Architect支持的13种UML图的技术概览。UML 2 详细的语义解释请看新的 UML 2 教程 。 首先... 什么是UML? OMG组织规范声明 : "统一建模语言(UML)是一种图形化的语言，用于软件密集系统要素的可视化、制定规范、构建对象和编写文档。UML提供了一种标准的方式来描述系统的设计图，既包括概念方面，例如业务过程和系统功能，也包括具体事务，如编程语言语句，数据库图示和可重用的软件组件。 这里着重指出的是UML是一种说明性的“语言”，而不是一种方法或程序。UML通常用来定义软件系统与细化、编写、构造系统中的要素，是“写”设计图的语言。UML可以用不同的方式来支持软件开发方法(例如：统一软件开发过程)-但是它本身并不指定某种方法或过程。 UML 定义了下列领域的标注和语义: - 用户交互或 用例模型 -描述系统和用户之间的界定和交互。在某些方面对应于一个需求模型。 - 交互或通信模型 -描述系统中的对象彼此之间如何进行交互以完成工作。 - 状态或 动态模型 -状态图表描述随着时间变化，类所呈现的状态和条件。活动图则描述系统即将执行的工作流程。 - 逻辑或类模型 - 描述构成系统的类和对象。 - 物理 组件模型 - 描述构成系统的软件(有时也包含硬件)。 -

本文通过学习原文： 1、https://blog.csdn.net/haoyoumo/article/details/43267121 2、https://blog.csdn.net/weixin_42369687/article/details/90106419 3、https://blog.csdn.net/yoyo328/article/details/78009237 将其整理在此处，方便使用。 UML中用例图的作用及画法 用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。 当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。它将系统功能划分成对参与者（即系统的理想用户）有用的需求。而交互部分被称作用例。用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。 用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系

用例图 用例图是用来描述系统功能的技术，表示一个系统中用例与参与者及其关系的图，主要用于需求分析阶段。 用例图的基本组成元素：参与者、用例、元素之间的关系。 用例图使用范围：需求分析 1.捕获需求。描述功能需求、行为需求（系统要完成什么任务） 2.分析需求。明确类和对象，建立之间的关系 用例图的基本概念 1、用例图是表示一个系统中用例与参与者关系之间的图。它描述了系统中相关的用户和系统对不同用户提供的功能和服务。 2、用例图相当于从用户的视角来描述和建模整个系统，分析系统的功能与行为。 3、用例图中的主要元素包括参与者、用例以及元素之间的关系。此外，用例图还可以包括注解和约束，也可以使用包将图中的元素组合成模块。 如： 参与者的概念 1、参与者是与系统主体交互的外部实体的类元，描述了一个或一组与系统产生交互的外部用户或外部事物。 2、参与者位于系统边界之外，而不是系统的一部分。 3、参与者是从现实世界中抽象出来的一种形式，却不一定确切对应的现实中的某个特定对象。 符号： 如何确定参与者？ 通过对参与者进行关注和分析，我们可以把重点放在如何与系统交互这一问题上，便于进一步确定系统的边界。另外，参与者也决定了系统需求的完整性。 确定参与者可以从以下几个角度来考虑： 1）为系统提供输入的人或事物 2）接收系统输出的人或事物 3）需要接入的第三方系统或设备 4）时间是否会触发某些事件 5