uml新闻中心管理系统_uml用例图

UML–类图、活动图　　我为什么学习UML 　　作为一个产品小白，在打怪升级过程中，我最大的感触，就是产品设计流程的复杂性、产品系统架构的复杂性、不同行业产品的差异性和多样性。最初，作为一个用户，我只看到了产品的表现层或者说前台；后来，从产品系统设计的角度，我看到了从战略到界面的设计流程，或者说从用户需求到产品功能；到现在，我亲自去实践一个项目，则看到了产品系统架构的中后台，它们共同支撑了前台产品功能的实现。　　我所做的也是一个系统庞杂的项目——新零售下的智能门店管理系统，这样一套管理系统，涉及到的用户包括零售商、消费者、供应商、物流配送人员，如果是零售企业，还会涉及一层一层的部门和不同管理权限。面对复杂，我们必须有一套应对方法。UML所代表的一系列业务逻辑、业务概念、业务流程图表，就是一套解决方法，它提供一种思考方向、一种表达方式、一套话语体系。　　更具体的来说，在进行完战略分析、进行了用户研究，通过用户画像或者其他报表，描述了目标用户、用户目标和需求；我们通过分析竞品、头脑风暴，将用户需求转化为许多不同粒度大小的产品功能；接下来，我们该思考，如何将这些功能模块组装起来，成为一个统一的系统？或者我们由于种种原因找不到类似的竞品，头脑风暴也不大奏效，这时又该怎么办？　　我就遇到了这两个问题。参考了《赢在用户》、《洞察用户体验》这两本书，作者提到的思路主要是：用户场景（情景故事）– 任务分析（流程图、网格图、塔图）– 整体架构 — 界面与内容，这种思路可以说偏重用户视角，是从前台推到后台。后来又看了《UML大战需求分析》，这本书偏重系统视角，将用户、信息、活动同时纳入系统，是一种从“静态的整体架构（类图）– 动态的活动流程（活动图）– 页面与内容”的思路，通过对系统的结构和流程建模，将用户、活动、系统功能、信息串起来，更容易在错综复杂的系统中看到静态模式与动态走向。以上这两种思路殊途同归，互相补充，最终也都表现为各种相类似的图表。　　实际当中当然是活学活用（废话一句），此文主要讲解UML的思路和应用。　　简介　　UML（unified modeling language）,即“统一建模语言”,也就是在软件系统开发中用于沟通交流的一种图形“语言”／标准。而实际上，如果你进一步了解就会发现，UML不仅是一套标准，还是一种思维方式（我们往往不是想好再下笔画，而是通过画图来思考）、一种解决问题的方法。它可以用于软件设计开发，还可以用于需求分析，还可用于辅助日常各种问题的分析与思考。当然，除了UML，还有其他许多标准和表达方式，UML只是其中之一。　　分类　　UML所有的图形，可以归为两大类：结构型的图和行为型的图　　结构型的图（structure diagram）主要用来表达静态的业务概念之间的关系，是锻炼面向对象分析（OOA）和面向对象设计（OOD）思想的重要工具，是业务结构建模的重要工具，包括以下几种：　　类图（class diagram）　　对象图（object diagram）：学编程的朋友最熟悉不过，类的实例就是对象　　构件图（component diagram）　　部署图（development diagram）　　包图（packagediagram）　　行为型的图（behavior diagram）主要用来表达动态的流程，是业务流程／行为建模的工具，包括以下几种：　　活动图（activity diagram）　　状态机图（state machine diagram）　　顺序图（sequence diagram）　　通信图（communication diagram）　　用例图（Use Case diagram）　　时序图（yiming diagram）　　类图（class diagram）　　1作用：描述软件系统中的人、物品、事情、业务概念之间的关系，进行静态的结构建模　　2类的划分：根据系统目标、业务需要，选取合适的角度进行分类　　3只有一个类的类图：类的名字、属性(+表示public)、操作（一般用不到）　　

　　4表达类之间的关系：只需画出类名，省略属性方法（分别对照下面的图）　　4.1关联关系：有关系但不确定具体关系如何。下方标注数字代表数量对应关系，上方可以用汉字标注角色关系，箭头代表导航关系。　　4.2包含关系：空／实心菱形表示弱／强包含，术语为聚合／组合　　4.3泛化关系：A泛化为B，A继承B。如企业培训中，老师和学生都可以泛化为员工。B可以是一种抽象类（用斜体字写类名）　　4.4依赖关系：A依赖B 　　4.5递归关系：一个文件夹里有很多文件夹，每个文件夹里还有很多文件夹或文件　　4.6关联类：公司与雇员通过劳动合同建立联系

　　自包含的递归　　

　　自关联的递归　　

　　关联类　　

　　5实战操作：　　5.1 从系统目标出发，识别出核心类　　5.2 识别出核心类的主要属性　　5.3找出相关类和其属性　　5.4描绘出类之间的关系　　5.5读图、修改、优化　　6 注意：　　6.1 不要试图用一个类图表达所有内容，适当拆分　　6.2 只需画出直接关系，不需画间接关系　　6.3 识别出“原生属性”和“导出属性” 　　6.4 注意识别关联类，能帮助看清事情的本质　　7练习　　下面以我做的智能门店管理系统为例，讲解一下类图。　　7.1系统目标：通过这个系统，零售商可以高效、数字化地管理线上线下的商品（进销存）、订单、账目、客户；通过这个系统，消费者可以在线上线下便捷地购物、支付。　　7.2核心类：门店管理　　7.3类的属性：管理者、管理时间、管理对象、操作等　　7.4相关类：账目管理、订单管理、商品管理、客户管理、购物、支付、零售商　　7.5相关属性：管理者、管理时间、管理内容、操作等　　7.6关系描述　　

　　上图表明：门店管理包含客户、商品（进销存）、订单、账目的管理；客户、商品、订单、账目这四者存在相互依赖的关系；客户和商品通过购物建立关系，而订单和账目通过支付建立关系；支付依赖于购物；零售商是店铺的管理者或拥有者。　　活动图（activity diagram）　　1作用：表达业务流程（与流程图很相似），进行动态的行为建模　　2流程图：矩形表示步骤、菱形表示判定，判定文字写在菱形内　　3活动图基础语法：开始状态、结束状态、活动（圆角矩形、主动宾）、判断（小菱形）、监护（[ …]）、合并

　　4判断的三种表示　　4.1通过监护表示判断，如上图　　4.2在菱形旁边写下判断，如下图　　4.3菱形前增加一个表示判断的活动

　　5泳道（swimlane）／分区(partition): 更好表达活动的发起者

　　注意，开始、结束，判断、合并可画在任意泳道；如果某一角色执行判断，则要将判断抽离为一个活动，画在相应的泳道　　6 并行活动　　加黑的短线分别表示并行活动的分叉（fork）和汇合（join）　　

　　7对象与对象流：可理解为工作的产出物，用于表达活动的输入或输出　　矩形、下划线、名词（短语）、箭头／对象流；注意圆角矩形表示活动，要使用动宾结构，箭头表示控制流　　

　　8活动与动作：动作是不可再细分的活动

　　9实战操作：　　9.1 明确业务目的　　9.2识别（主要）参与角色　　9.3画出正常情况下的流程主干，包括角色与活动　　9.4画出特殊情况下的分支流程，适当添加注解　　9.5 控制活动粒度，进行细化　　9.6思考与优化；可以先画出流程现状和然后改进流程　　9.7整理出优化前后差异，表达总结与沟通　　10练习　　依旧是前面做的智能门店管理系统项目，主要针对商品进销存管理绘制活动图　　10.1业务目标　　进：根据店铺销售情况智能推荐零售商进货的品类、品牌、数量、供应商、物流公司以及相关协议等，零售商可在系统中订货，系统自动记录更新数据。　　销：每日、周、月、半年、年度销量统计，更新同步与数据分析可视化；满足不同场景（如线上APP订单、线下实体店订单）的数据录入与更新　　存：每日、周、月、半年、年度存量统计，更新同步与数据分析可视化　　10.2主要角色：零售商、消费者、供应商、物流、系统平台　　10.3要素：谁、从哪里开始、到哪里结束、哪些步骤、哪些资源／工具、哪些内容　　10.4主干流程　　

　　10.5添加分支流程　　

　　10.6缩小粒度　　10.7思考、优化　　太烧脑了，目前先写到这里，后面不断优化。。。

uml新闻中心管理系统_uml用例图

相关推荐