软件设计之UML用例图大白话教程

发表于:2023-8-15 09:33

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:PDDON    来源:知乎

  1、为什么要使用UML用例图?
  对一个复杂问题或者现象的分析,好的方式方法往往能带来事半功倍的效果。比如在软件开发领域,参与的人员角色各种各样,比如软件开发工程师、产品经理、客户、运营人员、老板、用户、B端客户等等,而我们开发软件的初衷是为了解决用户的问题或者方便用户的工作生活,首先就需要收集用户的需求,而需求来自哪里呢?有如下几种方式可以获得需求的来源:
  · 用户需求
  首先是用户需求,是这个产品的目标用户想要什么,而不是你想要什么,站在用户的立场去考虑产品应该具备什么样的功能解决用户的痛点,提供用户想要的。所以需要去调研、收集你的目标用户的需求。
  · 客户需求
  有些产品是针对B端客户的,那B端的客户想要什么,产品应该具备什么样的功能满足客户的需求。需要调研客户的需求。
  · 产品经理
  无论做什么产品,都必须要有一个产品经理,产品经理主要负责产品的需求调研、分析、设计、规划等等工作,产品经理对于软件产品的开发很熟悉,熟悉用户体验的设计,所以为了能让用户有更好的体验,产品经理也会有很多的需求,想要把这些需求在软件上实现。
  · 运营人员
  不管是什么样的软件产品,其实也是和用户建立联系的一种渠道,通过这个渠道的运营,让用户能够来使用产品,那么产品本身需要具备运营的功能,满足运营的需求。因此也需要去和运营的人员去分析,收集运营的需求。
  · 竞争对手
  在产品中,有个工作叫竞品分析,通过分析竞争对手的产品,发现竞争对手产品的问题,包括市场需求解决问题和用户体验问题,而这些问题就是你的产品需要去改变的,也是发展的机会。所以很多创业者把竞争对手的产品直接拿过来仿照去开发的方式肯定是不可取的。
  · 开发人员
  产品设计出来后,具体开发还是需要技术人员去实现,但是并不是所有的方式都可以很好的实现,而且开发人员对于前沿的用户体验等都较熟悉,因此也会提出一些需求。
  在设计软件的初期,面对不同领域、不同角色、不同身份的需求人员,为了能一起把这个软件的所有需求点确定出来,想想都是一件不容易的事情。首先就是沟通问题,传统的方式是产品经理收集各方反馈的需求整理成PRD,给到研发人员,研发人员再按PRD进行研发设计,然后进行编码开发软件。
  在前面分析的整个软件开发过程,就可以看做是对需求信息流进行加工并传递,直到输出软件成品。如果沟通不到位、信息的传递出现误差,做出的成品软件肯定无法满足需求的初衷,这样的软件也是失败的。那么有没有一种方法,让所有需求提供人员都能参与其中,能直观的和大家讨论、沟通软件的需求、功能点呢?
  这个时候UML用例图就非常关键了,它是以一种所有人都易于理解的图解方式进行呈现的,也称为统一建模语言,不同角色、领域的参与人员都能直观的了解到整个软件的需求点、功能点、参与角色等信息,并能提出自己的需求、讨论需求,通过所有参与方的仔细沟通后,确定下来的成品就是UML用例图。
  UML用例图对产品经理的PRD设计有着指导作用,设计出来的功能需求也很难再偏离需求提供方的初始意图,因为全程都有开发人员一起参与,开发人员在拿到产品经理提供的PRD后也能起到一个监督和反馈的作用。
  总结一句话就是,UML用例图是一种以图表形式的标准化建模语言。当然UML除了用例图,还包含活动图、状态图、时序图、类图、组件图、包图、部署图等等,本文仅为大家讲解用例图的使用场景以及如何使用,后续也会对其他类型绘图的使用做讲解,喜欢的朋友可以点赞支持、持续关注更新哦!
  2、UML用例图使用场景
  简单来说,需要描述一个系统的动态视图时,就可以使用UML用例图,常见的使用场景有:
  ·软硬件参与角色与功能点需求分析
  · 分析并策划一场活动的参与方、节目安排等等
  · 对一个产品的使用人员、功能点进行分析
  · 对一些人群的类型、行为进行分析
  · 对一些生物的生活习性的分析
  其实生活中还有很多类似上面的场景都可以使用UML用例图来描述,只要使用得当,效果一定会事半功倍的。
  3、UML用例图组成结构分析
  用例图(Use Case Diagram):描述了人们希望一个系统应该提供怎样的服务给自己使用,将系统参与方、功能服务、及他们间的使用关系更清晰的展示出来,以便使系统用户、系统开发人员和其他参与方更容易理解这些元素的用途,也便于开发人员最终实现这些元素。
  之所以说用例图至关重要,是由于用户并不关心系统的实现和内部结构,只关心产品所呈现出来的外部行为特征。而用例图恰好就是描述软件产品外部特性的视图,它从用户的角度而不是从开发者的角度来描述需求,分析产品的功能和动态行为。
  用例图包括四方面内容:
  · 用例(Use Case)
  是对系统的用户需求(主要是功能需求)的描述,用例表达了系统的功能和所提供的服务,描述了活动者与系统交互中的对话。用椭圆形表示。
  · 参与者(Actor)
  参与者是系统外部的一个实体,它以某种方式参与了用例的执行过程,在UML中,通常用名字写在下面的人形图标表示。
  · 参与者、用例之间的关系
  参与者与用例之间的关系主要包括关联、泛化、包含、拓展。以连线+描述的方式表示
  关联
  表示参与者与用例之间的关系:
  泛化
  表示参与者与参与者之间、用例与用例之间的关系。一个用例可以被特别列举为一个或多个子用例,这被称为用例泛化。
  包含
  表示用例与用例之间的关系,其中一个用例的行为包含了另一个用例的场景,另一个用例的行为作为该用例的行为的一部分。
  拓展
  表示用例与用例之间的关系,拓展用例是在满足一定条件下对基础用例的补充。
  · 系统边界
  系统边界是指系统与系统之间的界限。用方形容器+系统名称表示。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号