38

业务建模--建模工作流与UML | 产品壹佰

 5 years ago
source link: http://www.chanpin100.com/article/109854
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

业务建模--建模工作流与UML | 产品壹佰

关闭
159298611617776968

业务建模--建模工作流与UML

介绍建模工作流，以及对应的UML图

本文为《软件方法-业务建模和需求》的读后感系列，可在线试读

上一篇为《业务建模-竞争优势》，markdown表格支持有一定的问题，此次把表格转成截图

软件工程中阶段中的的计划、需求分析和设计阶段，都需要进行建模：

157223375919353517

软件开发人员如果对以上工作流没有概念，就会把这些工作通通称为“设计”或者“文档”，产生以下误解：

  1. 例如问开发人员在做什么，回答“我在做设计”、“我在写文档”，其实他的大脑可能正在思考组织的流程（业务建模），或者在思考系统有什么功能性能（需求），或者在思考系统要包含的领域概念之间的关系（分析），但他通通回答成“在做设计”、“在写文档”
  2. 又有牛人认为“代码就是设计”。本来“设计”在他脑子里就是“代码以外的东西”，这么一推导，不就变成了：代码就是一切？
把工件简单分割为代码和文档（或设计），背后还隐含着这样的误解：认为模型（文档）只不过是源代码的另一种比较概要或比较形象的表现形式。
不同工作流产出的工件之间的区别不在于形式，而在于内容，也就是思考的边界
建模工作流思考边界

UML建模

建模不一定非要用UML，也可以用文本或其他自造符号来表达。每个项目中，团队一定会思考和表达建模思想，只是可能无意识、不严肃的做。

UML全称Unified Modeling Language，翻译过来叫做统一建模语言，是非专利的第三代建模和规约语言。

为何钟爱UML

大家看看有没有遇到这种情况：开会讨论问题，某些人就是白板手绘草图，“来，我给大家讲讲”。我感觉这种特别常见，基本是画流程图和活动图、时序图的混合体，以及ER图、类图糅杂砸一起。

这样的做法有巨大的“优点”：怎么画都是对的，关于这个草图的解释权归“我”所有。同事不好批评“我”，项目要依赖于“我”头脑中的隐式知识——要是“我”不“给大家讲讲”，大家就玩不转了。这样，“我”在团队里的地位就提高了。上面这种现象，在有一定资历、但又不对项目的成败承担首要责任的“高手”身上表现更明显。
这种做法的本质是想通过形式上的丑陋来遮掩内容上的丑陋。
掌握统一的建模语言之后，开发团队在基本共识上沟通，会大大提高沟通的效率和深度，有意无意遮掩的脓包也会强制露出。开发人员如果习惯于画“草图”，用“模块”、“特性”等词汇含糊不清地表达思想，在严谨建模思维的追问之下，往往会千疮百孔，暴露许多之前没有想到的问题。

作者特意提到：

使用UML沟通仅限于软件组织内部，UML模型不是用来和涉众沟通的！

跟客户沟通，还是Visio那种流程图、泳道图合适。跟客户谈业务流程，这种形式更合适。

建模UML图

UML2.5中，已经有14种图：

UML图形

不是所有图都要在建模工作流中使用，下面是建模工作流推荐的UML图：

工作流推荐图

可选和推荐的建模元素用法（●：优先使用，√：可以使用 ）

这里简单介绍下使用的UML图形

简单来说，用例图的目的如下： 用例图用来收集系统的要求 用例图用于获取系统的外观图 用例图识别外部和内部因素影响系统 用例图显示要求之间的相互作用是参与者。

下面是一个示例用例图，代表订单管理系统。因此，如果我们看看图，那么我们会发现三个用例（订单，特殊订单和正常订单）和一个参与者：顾客。

订单用例图

SpecialOrder 和NormalOrder 从订单使用情况扩展。因此，他们扩展了关系。另外很重要的一点是确定系统边界，这是图中所示。参与者是客户以外的系统，因为它是系统的外部用户。

再举一个包含关系的例子：

用例图1_包含

包含关系描述的是一个用例需要某种功能，而该功能被另外一个用例定义，那么在用例的执行过程中，就可以调用已经定义好的用例

类图可以用来：描述系统的静态视图。显示静态视图中的元素之间的协作。由系统执行的功能的描述。构建软件应用面向对象的语言。

举个例子：

类图
  • 车的类图结构为<>，表示车是一个抽象类；
  • 它有两个继承类：小汽车和自行车；它们之间的关系为实现关系，使用带空心箭头的虚线表示；
  • 小汽车为与SUV之间也是继承关系，它们之间的关系为泛化关系，使用带空心箭头的实线表示；
  • 小汽车与发动机之间是组合关系，使用带实心箭头的实线表示；
  • 学生与班级之间是聚合关系，使用带空心箭头的实线表示；
  • 学生与身份证之间为关联关系，使用一根实线表示；
  • 学生上学需要用到自行车，与自行车是一种依赖关系，使用带箭头的虚线表示；
序列图
UML 状态图是图表本身的名称，主要用于描述对象具有的各种状态、状态之间的转换过程以及触发状态转换的各种事件和条件。
使用状态图的主要目的： 为了模拟系统的动态环节 反应系统模型生命周期 一个对象来描述不同的状态，在其生命周期的时间。 定义一个状态机模型状态的对象

当发生特定事件时，对象可能会发生状态的变动。

绘制状态图之前，我们必须明确以下几点：

  • 识别对象，以进行分析
  • 识别对象的各类状态
  • 识别各类的事件，尤其是直接导致状态改变的时间

举个例子：

状态图
UML 活动图能够捕捉到该系统的动态行为，UML 中其它的四个图是用来显示从一个对象到另一个消息流，但活动图是用来显示消息流从一个活动到另一个活动图。以下是 UML 活动图目的描述： 绘制活动流程系统 描述的顺序从一个活动到另一个 描述系统并行，分支，并发流。

以找饮料为例子：

活动图1_分支

上述的图将人视为开始起点有些奇怪，整体上是没有问题的。

包含子活动，如下图所示：

活动图2_子活动

其中pay for the book为子活动，子活动的结束符号可能是其他样式

博客原文链接:https://bakerhancockchen.github.io/2019/04/23/ye-wu-jian-mo-jian-mo-gong-zuo-liu-yu-uml/

本文章著作权归作者所有，任何形式的转载都请注明出处。


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK