UML建模

news2024/9/20 14:31:35

UML定义了行为图（动态）和状态图（静态）两大类。（分类依据：对象是否根据时间变化）
下面简介一下用例图、类图、时序图和状态图的概念。

“4+1”视图模型

逻辑视图：逻辑试图主要是用来描述系统的功能需求，即系统提供给最终用户的服务. 在逻辑视图中，系统分解成一系列的功能抽象、功能分解与功能分析。在面向对象技术中，通过抽象、封装、继承,可以用对象模型来代表逻辑视图，可以用类图（Class Diagram）来描述逻辑视图。
开发视图：开发视图主要用来描述软件模块的组织与管理（通过程序库或子系统）。服务于软件编程人员，方便后续的设计与实现。它通过系统输入输出关系的模型图和子系统图来描述。要考虑软件的内部需求：开发的难易程度、重用的可能性，通用性，局限性等等。开发视图的风格通常是层次结构，层次越低，通用性越好（底层库：JavaSDK，图像处理软件包）。
进程视图：进程试图侧重系统的运行特性，关注非功能性的需求（性能，可用性）。服务于系统集成人员，方便后续性能测试。强调并发性、分布性、集成性、鲁棒性（容错）、可扩充性、吞吐量等。定义逻辑视图中的各个类的具体操作是在哪一个线程（Thread）中被执行。
物理视图：物理试图主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射。

在这里插入图片描述

用例图

用例图的作用：是动态视图，是需求分析产物，主要作用就是描述参与者和用例之间的关系，帮助开放人员了解系统的功能。
由参与者（Actor）、用例（Use Case）以及它们之间的关系构成。其中用例和参与者之间的对应关系又叫做通讯关联（Communication Association）。

用例图的构成元素有四个：参与者（角色）、用例、系统边界和元素

参与者（Actor）：系统外部并且直接与程序或者系统接触的人、系统、子系统的外部实体的抽象，在UML中使用一个小人来进行表示。
用例：用例即使外部可见的系统功能，对系统提供的服务来进行描述，使用椭圆来进行表示。
系统边界：指系统与系统之间的界限，使用方形框+系统名称来表示。
元素间的关系有四个：关联、泛化、包含、依赖
- 关联：参与者与用例之间的关系，，如何一方都可以接收或者发送信息（箭头指向信息接受方）实线实心箭头。——>
- 泛化：是类元一般描述和具体描述之间的关系，具体描述建立在一般描述的基础之上，并且对其进行了扩展。具体描述完全拥有一般描述的特性、成员和关系，并且包含补充信息（类似于Java这继承关系）。实线空心箭头。
- 依赖：类A的实现需要使用到B，这就是依赖，这种使用关系是具有偶然性、临时性、非常弱的，并且B类的的变化会影响到A，则A与B就是存在依赖关系，依赖关系是弱的关联关系，例如：人们依赖计算机去做软件的开发。虚线+箭头 --------->
箭头+虚线不仅仅可以代表依赖关系，还可以代表扩展、包含关系，扩展就是对用例功能的延申，包含就是将一个复杂的功能分解成数个小的功能


总结：用例图实是动态的面向用户的包含用例（系统提供服务）、参与者（外部实体），重点在于两者之间的关联有关联、泛化、依赖三种关系。关联是参与者和用例，用实心实线箭头；泛化和继承一样，用实线空心箭头；依赖有包含（功能分解）和扩展（功能延伸）两种。关联最实在；泛化毕竟是继承，线条是实在的，但是儿子可能是空的；依赖最不可靠，线条都是虚的，依赖可能是依赖子功能（没他不行），可能是依赖扩展的功能（有他更好）。
参与者：外部实体、名词
用例：系统服务、动词

   绘制范例：

在火车票预订系统中，客户可以进行购买车票、退订车票、查询余票和查询列车时刻四个操作。不管是购买车票还是退订车票，用户都必须先进行登录系统操作。其中查询列车时刻主要包括按站站查询和按车次查询两种方式。如果在登录系统的过程中忘记密码，则还可使用找回密码功能。

在这里插入图片描述

在学生信息管理系统的“网上选课模块”中，学生可以进行“查看课程信息”、“选择课程”和“删除已选课程”三个操作。“查看课程信息”主要包括“按课程编号查看”和“按课程名查看”两种方式。管理员可以进行 “维护课程信息” 操作。学生和管理员的所有操作均需“登录系统”后方可完成。如果在“登录系统”的过程中忘记密码，则还可使用“找回密码”功能。

在这里插入图片描述