2008年10月15日,星期三,06:26

Nearly 疼痛less UML

由拜伦·克拉格霍恩(Byron Claghorn)撰写

UML(统一建模语言)是一项重要的技术进步,可以正式指定,可视化和记录对业务流程和系统的现有和预期的改进。  UML是由三位软件工程负责人的共同努力建立的,每个人都有自己的形式化方法: 格雷迪·布奇(Grady Booch),詹姆斯·朗博(James Rumbaugh)和伊瓦·雅各布森(Ivar Jacobson)。

他们能够创建一套通用的形式化概念,图示约定和方法,以促进清晰,高效的通信,从而有效地满足面向对象程序,数据库系统和基于Web的应用程序的传统和现代需求。 从那以后,UML已发展成为软件工程最佳实践的行业标准,并得到Microsoft Visio等工具的支持。 

尽管UML概念在改善现有流程和业务需求与业务管理人员之间的沟通方面具有很大的潜力,但它们的潜力通常难以在实施中实现。

传统观点认为,与为技术人员成功完成的课程类似,UML的培训课程为期数天,以培训UML中的关键业务用户。  但是,激励和培训已经忙碌的高管,业务管理和员工"cram UML course"通常它是压倒性的和无效的,而且由于其复杂性和实际的严格性,它很容易对UML和需求定义过程产生普遍的消极态度。

The "Painless" UML Alternative
对UML有了很好的理解和掌握的业务分析师可以识别当前的业务流程和问题,并使用UML传达对业务改进的愿景。  通过运用一些额外的想象力和独创性,他们可以创建有效的图表,图表,ROI分析和功能规范,以UML传达有意义的业务概念,从而使业务管理人员,职能区域人员和技术人员可以轻松理解这些概念。 不提UML.  

这些规范和演示文稿通常可以基于UML概念,图表和方法,而无需使业务社区受到严格和严格的要求。"Pain"正式的UML培训。   业务分析师及其业务客户的主要目标是建立有效的通信-仅当训练所有人使用相同的准确约定或与UML培训的人员进行交流时,在哪个图中使用哪种类型的箭头的细节才很重要。执业技术人员。

在许多组织中,UML通常不被管理人员,管理人员和非技术人员所关注,也不是它的优先事项-也不一定如此。  根据作者的经验,可以使用有效的UML和非UML图进行有效的通信,以巧妙地开始引入高级UML概念,例如面向对象的继承,用例,功能泳道和业务流程,以更好地理解和理解。交流业务概念。  以这种方式,如下所述,以更自然的方式有效地引入和逐步学习了这些高级概念。

在许多情况下,创新的业务分析师可以巩固业务发展的总体情况 应该起作用,实际上起作用 要么 应该更好地工作 变成一张图片"值一千字"阐明,沟通和帮助做出正确的业务和/或技术决策(如下例所示)。

painless1.png

如上所示,在高级图中传达的概念可以进一步分解为功能组件和易于理解的详细规范 painless2.png技术人员和非技术人员都可以理解。  由于工作人员已经熟悉他们的业务,因此他们现在可以更好地了解整个图景,并可以轻松地掌握图中的继承和新概念,例如继承(IS-A关系)。

面向对象的UML继承图(在右侧)清楚地描述了仓库的人员配置,该图显示了仓库工作人员承担的不同角色。  

同样,可以使用相同的方法来定义其他类型的对象,例如产品或设备,以明确指定常规类型和子类型。

可以从一个较高的层次介绍所提出系统的功能愿景(如下所示),然后随着功能设计方法的进一步详细介绍,随后会更详细地显示。

painless3.png 

以下示例显示了系统的功能设计,因为它影响到不同的部门和职能组织以及主要的输入和输出信息源,

painless4.png

三个独立的垂直区域称为"Swimlanes" in UML. 上图清楚地显示了以下功能和高级流程:销售自动化,生产管理和调度&路由是否知道UML。

由于业务流程是在其他详细级别定义的,"Use Cases"是识别业务对象以及应用程序必须支持的对象的业务操作的一种非常有效的方法,如下例所示。

painless5.png

用例图通过显示先前继承图中定义的每种类型的工作程序可以执行哪些操作,提供了更多详细信息。 

用例图还采用了技术人员和非技术人员都容易理解的继承关系。 

这些图和方法提供的清晰性使功能用户可以捕获遗漏和错误,例如:  allowing the 包装和运输任务,但忘记了您还必须提供任务 接受并处理退货 作为项目审查和讨论的一部分。  

用例图对于面向对象的软件开发项目尤其重要,因为它们通常成为有关如何设计和构造对象和程序的指南。

随着业务分析师继续了解将要集成的新的手动和自动化流程,许多不同仓库的新职能组织开始以图表的形式出现,以帮助职能,技术和管理人员进行有效的讨论,审查和创新参与(如下图所示)。

painless6.png

这些示例只是业务分析师在理解和创建当前流程的有效画面以及改进手动和自动业务流程的愿景方面的几种方法,可以逐步地逐步发展出这些方法。

清晰有效地交流业务事实和需求有助于使技术人员和非技术人员在同一页面上,并带来更好的项目结果。 

In Summary
This "Painless UML"案例研究提供了一些示例,说明如何以一种自然的方式逐步以业务人员自然的方式介绍和讨论UML甚至与复杂的概念,以易于理解的格式提出他们自己的业务需求和流程,并做出额外的努力以确保员工理解它。

完整的UML(统一建模语言)非常广泛,其许多功能,图表和细微差别主要是技术人员所关注的-"Under the Hood",可以说在机械师和工程师的世界中。  同样,您只需要了解汽车的驾驶控制方法,就像只有一部分UML才能有效地发挥作用一样 业务人员业务分析师 在需求定义和审查过程中进行沟通。

业务分析师是有效应用"Nearly 疼痛less UML"不仅可以为技术社区提供卓越的规范,还可以使业务社区专注于沟通,审阅和收集业务需求信息的有效性,而无需提及UML。


拜伦·克拉格霍恩 是Point North Consulting企业发展总监。 在此职位上,他能够利用其丰富的经验来开发和支持各种Point North Consulting实践和我们的服务产品。 他拥有漫长而多样的计算机科学,工程学R&曾在Burroughs和Unisys公司工作,担任咨询工作,曾担任Microcard Technologies工程和制造部副总裁以及空军数据自动化官。他的大部分职业集中在软件产品和应用程序开发工具的开发,特定于客户的文档成像技术与现有计算机化应用程序,数据库和主机系统的集成。拜伦可以在 [email protected] 或407-514-2651

©BA Times.com 2020

麦格雷戈徽标白色网站