pt电子游戏


  • pt电子游戏 > 产品中心 >
    • 产品中心

    UML图绘制的注意点和实例分析

    发布作者:pt电子游戏  发布时间:2019-04-04

      又称统一建模语言或标准建模语言,是始于1997年一个OMG标准,它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持,包括由需求分析到规格,到构造和配置。

      UML可以看做用于系统设计阶段给开发做参考的一种方式,其很多图需要用到面向对象程序的思维。画UML图是产品经理的必备技能之一。

      废话不多说,本文介绍一下最常见的几个UML图:类图、用例图、状态图、序列图、活动图,以及一个并不属于UML,但也有很大作用的数据流图。每张图详细介绍一下画法、注意点和具体案例。相关的概念、元素等则简单介绍。

      类图是UML图中看起来最复杂的一个图。它与数据库和面向对象编程的联系比较紧密。没学过面向对象或者数据库的同学刚开始画类图可能比较吃力。

      一句话介绍一下类:类即相同属性、操作、关系和语义的对象的描述。类的组成:属性、操作。

      类图描述系统中类的静态结构。它的作用是定义系统中的类, 表示类之间的关系(关联, 依赖, 聚合等),描述类的内部结构(属性, 方法等)。一个类长什么样看下图。

      类图有涉及到面向对象的知识,在此不一一叙述。图中有些看不懂的名词请自行百度。

      类之间通过关系连接起来。类图中的关系很多,在此介绍最常见的关联关系。关联关系是一种拥有的关系,它使一个类知道另一个类的属性和方法。关联关系的类通过箭头连接起来。

      下面分析具体案例:公司图书管理系统,包括借书、还书、申请买书的操作。借书过程:员工发起借书申请,由行政人员去图书馆拿书给员工。还书买书类似。后面的图也是用这个案例。

      这幅图就是借书系统的类图。要简化的话可以将可见性符号和属性的类型省略。图中的空心三角形应该为箭头。

      员工、书、订单三个类比较容易理解,代表了三个抽象的实体。借书类则是员工和书之间借书行为的一个抽象,连接了员工和书,记录了借书这个状态中的一些信息,以及借还书操作。买书同理。

      。比如书这个类有上架下架的操作,是书自己被上架下架,不能因为上架下架是管理员的动作而把它放在管理员的操作里。

      两个相关联的类,需要在关联的类中加上被关联类的ID,并且箭头指向被关联类

      。可以理解为数据表中的外键。比如借书和书,借书需要用到书的信息,因此借书类需包含书的ID,箭头指向书。

      由于业务复杂性,一个显示中的实体可能会被分为多个类,这是很正常的,类不是越少越好。

      。比如单看逻辑,借书类可以不存在,它的信息可以放在书这个类里。然而借还书的书的上架下架完全不是一回事,借书类对借书的操作更加方便,不需要去重复改动书这个类中的内容。此外,如果书和借书是1对多的关系,那就必须分为两个类。

      类图中的规范问题,比如不同关系需要不同的箭头(本文只介绍了1种关系),可见性符号等。

      用例图是最常见的一种图。用例图概括了用例中角色和系统之间的关系,描述了系统功能需求,角色和系统的交互以及系统的反应。

      用例图有参与者、用例、关系组成。参与者就是系统中的用户身份。用例是系统中的一个功能的概括。关系是参与者或者与用例的联系。其中关系可以分为关联、泛化、包含和扩展4种关系。关系的运用是用例图最难的部分。4种关系的说明:

      。比如吃饭和吃晚饭。两者的本质是一样的。符号用空心的三角形。箭头为被指向。

      。符号在箭头的线上加include。箭头为去指向。

      也是用例之间的关系,意思是一个用例可以扩展出一个子用例。与包含不同的是,

      ,没有也一样能完成功能。符号在箭头线上加extend。箭头为被指向。

      行政人员和员工是参与者,中间的这些是用例。这幅图用例之间大部分都是包含关系,比如借书包括申请、查找、借阅这三个子用例,都是必须的。而图书续借不是必须的,因此只是扩展的用例。批量购书是购书的一个特例,和购书本质是相同的,因此作为泛化的关系。

      状态图是UML中相对比较简单的一张图,用得也没前两种图多。状态图是描述一个实体基于事件反应的动态行为,显示了该实体所有可能的状态,以及事件发生时状态的转移条件。

      总结一句话,状态图就是把类的状态的改变连城一张图。状态图的元素包括状态、转移和动作。元素的形式如下图所示,黑点分别为起始点,矩形为状态,箭头上时状态改变的动作和事件。

      状态图可以看做是类图的补充,因为状态本身就是类的状态。状态图的绘制过程很简单,只要先把类的状态罗列,然后按顺序连起来,最后写上动作或条件即可。上图中连接线上依次为事件、判断条件和动作,简化起来只要写一个就行。

      序列图是用来描述对象之间消息发送的先后次序,阐明对象之间的交互过程以及系统执行过程某一具体时刻将会发生什么事件。抽象地概括,序列图就是把主体之间传递消息的操作以及消息本身按顺序排列出来。

      序列图的元素包括对象、生命线、控制焦点、消息。每个元素的样式如下图所示。

      序列图的消息主要分为3种,调用(同步),发送(异步),和返回。同步调用消息是指发送者把控制传递给接收者,然后停止活动,等待消息返回。它是一种即时的关系,返回消息需要直接放在这条消息之后。用实心的三角形表示(如上图的第一条线)。

      异步发送消息是指发送者把消息发送过去后,继续自己的活动,不需要等待消息返回来。返回消息可以在几个过程之后。用半个箭头表示(指留下上半个箭头)。

      返回消息就是上述两种消息调用后所返回的消息,用虚线和普通的箭头显示,如上图。

      从员工发起借书申请到借书成功的信息。对象之间的交互包括借书申请、查找、借书操作等。查找书和借书操作需要直接从系统返回消息。

      活动图是展示业务用例实现的工作流程,描述活动活动的顺序,展现从一个活动到另一个活动的控制流,强调每一步动作和产生的结果。也就是说,活动图将系统的活动连接起来,是流程图的详细化。

      活动图的元素有动作状态、动作流、对象、对象流、分支合并,泳道等。活动图的元素比较丰富,直接用图书馆的案例来分析。

      三块是泳道,分别是不同的对象。黑圆点是开始和结束,中间是活动和顺序。矩形是活动中需要涉及到的对象。粗线和菱形是合并分叉的标志。

      整个系统的业务流程如活动的顺序所示。发起借书申请时需要传递借书申请这个对象,因此需要添加对象。查找图书后的菱形分叉表示判断,分出两个不同的活动。粗线后的两个活动表示都在借书申请后一步执行。

      数据流图虽然并不是UML图,然而同样很重要,而且画图的难度比较大。数据流图简称DFD,它从数据传递和加工角度,以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程。简单的说,就是数据的流程图。

      数据流图的原理,就是把每个数据加工按照顺序用数据流连起来。系统外部输入和输出的数据则用外部实体来表达。每一步加工需要用到的数据存储,或者生成的数据存储,都用数据存储来表示。每个数据加工都需要按序号命名。

      由于系统数据的复杂性,不可能将所有数据操作画在一张数据流图上。需要进行分层操作,先画整体的数据流图即顶层图,再逐步细化,分为好几张图。

      由于系统比较简单,因此一共只有两层图。顶层是整个系统和外部的数据交换状态,底层是详细的数据流动。数据加工分为三块,借书申请检查,图书查找和图书借阅。借书申请由员工提交,合格的申请发给管理员。

      底层图的加工用1、2等数字命名。如果0层图后还有1层图,则用1.1,2.1来命名。如果有1层图,则需要分多张,如上图中的加工有1、2、3,则1层图要分3张,分别描绘这三步加工的详细步骤。

      ,不能多出来或少。比如上图顶层图中员工的借书申请,管理员的合格申请,在所有底层图中有且只能有这些数据,不能在员工和管理员的数据流中多出一个数据。

      。比如2图书查找和3图书借阅都有自己的子流程,那么2图书查找的数据流图结束后,就必须输出图书信息,3图书借阅的数据流图也必须要用到2传递的图书信息。这点原理和上一点一样。

      就写这么多。上述的案例是根据自身的业务来制定的,每个图的案例也有一些地方会不够完善。

      本文由 @潘帕斯雄鹰 原创投稿,并经人人都是产品经理编辑。未经许可,禁止转载。

      写的不错,但是过于简单,如果实例列举如微信,OFO,京东商品详情页等这些常用的会更好。

      人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。

          

    相关阅读:pt电子游戏

    
    Copyright © 2019 版权所有 pt电子游戏   
    pt电子游戏 | 网站地图