VP 版本的更深入概述

VP 版本的更深入概述

Visual Paradigm 提供 5 个不同版本的备受赞誉的设计和管理工具;从免费使用的社区版本(仅用于非商业用途)到适用于广泛企业架构的企业版。 尽管 VP 网站提供了不同版本及其版本的完整概述,但我认为从用户角度来看更深入的指南可能会很有用。 介绍 因为我是这个平台的新手,因为这是我的第一篇文章,所以我想我会介绍一下自己。我叫 Peter Looyenga,是来自荷兰的专业 Visual Paradigm 用户。Visual Paradigm 公司问我是否有兴趣成为 Visual Paradigm 技术作家,这就是结果。 我相信,在为建模语言和软件设计提供支持时,您将找不到像 Visual Paradigm 这样广泛和灵活的东西。所以我写这些指南不仅仅是因为 Visual Paradigm 公司和我之间的协议,我写这些也是因为我是一个忠实的粉丝,我真的相信这个产品和它背后的公司。 5 种不同的 VP 版本:哪一种最适合您? Visual Paradigm 是一个 CASE 工具(“计算机辅助软件工程”),它提供 5 个不同的版本。尽管更高级别的许可证肯定会为您提供更丰富的功能集,但记住每个版本都针对特定的受众也很重要。更多肯定会更好,但更多对你也更好吗?这就是我们将在本概述中探索的内容。 社区版 目标受众:热情的 UML 爱好者。 社区版是免费提供的(“像啤酒一样免费”)版本,它最显着地为您提供对 UML(“统一建模语言”)、SysML(“系统建模语言”)和 ERD(“实体关系图”)的全面支持)。但是,请记住,此版本仅供非商业用途。因此,您制作的任何打印输出或图像导出都将带有水印以强调这一点。 尽管社区版为您提供了一个完整的 UML 设计工具,其中还包括对数据库设计的支持。 建模者版 目标受众:专业建模师。 Modeler Edition 是专业建模的入门级版本。它提供社区版的所有功能以及对 BPMN(“业务流程建模和表示法”)、数据流图、业务模型图和文本分析图的支持。 接下来,它还允许您访问 Visual Paradigm Online;一个可以在 Visual Paradigm 内部使用的协作平台。它提供了各种各样的功能,但最重要的方面是: 敏捷驱动的项目管理。 Tasifier:一个强大的任务管理器来管理你的项目活动。 Postmania:一种协作功能,可让您共享图表并邀请其他人对其发表评论。 此版本非常适合对使用 UML 建模的基本软件设计以及通过 BPMN 进行业务流程建模感兴趣的人。另外值得注意的是,Modeler Edition 让您可以访问文本分析图,这是帮助您开始项目的宝贵工具。 标准版 目标受众:专业开发人员。 标准版是专为希望充分利用其工作的开发人员设计的版本。它支持以前版本的所有功能,并通过为数据建模过程提供更广泛的支持来增强这些功能。这方面的一些例子是项目引用、模型到模型转换(简而言之:“重用”模型元素的能力)、支持添加图表图例以及为相同的模型元素提供多个名称的能力,这可能非常如果您需要提供多种语言的图表,这很有用。 但由于代码生成等特定功能,它也可以将您的建模实践带入新的方向:基于您当前的图表集生成代码的能力。或代码反转:现在系统将分析您现有的源代码并基于它生成 UML 图。它也可以对数据库做同样的事情。 另一个重要的细节是对信息处理的广泛支持。思维导图、RACI 图表和用户故事等图表允许您收集和处理您需要的所有信息。然后,您可以使用文档编辑器根据您当前的项目快速生成报告。并具有完整的同步支持。如果 3000 多个默认模板无法提供您想要的布局,那么编写您自己的模板使用相对容易。 标准版非常适合需要 CASE 工具的专业开发人员,该工具可以帮助他们完成软件设计过程中的几乎每一步。从通过线框图创建功能设计到使用文档编辑器维护有关您的进度的详细报告。通过让系统分析您当前的源代码以生成一组基本图表来节省时间,或者使用 STEPS 向导帮助您完成设计过程并将您的问题分解为更易于管理的部分。 专业版 目标受众:专业数据分析师和开发人员等。 专业版将 Visual Paradigm 中的信息处理提升到了全新的高度,它提供了非常具体的功能集,这将吸引数据分析师和开发人员。与往常一样,此版本支持以前版本的所有功能,并扩展了这些功能。 一些值得注意的功能是客户旅程映射,它允许您完全可视化客户如何体验您的产品或服务,同时还提供了反思关键点、印象以及改进选项的方法。然后可以为所有用例添加额外的(背景)信息,这允许您在项目的其他区域中使用该信息,例如在由…continue reading →
ITSM:使用 Visual Paradigm 进行信息管理

ITSM:使用 Visual Paradigm 进行信息管理

当谈到 Visual Paradigm (“VP”) 时,我很肯定大多数读者会立即将该主题与建模或建模语言联系起来,就像我一样。而且我认为很难不这样做。毕竟,VP 是一个屡获殊荣的建模工具。 但是,尽管第一印象看起来非常清晰,但我认为当我们开始更深入地挖掘 Visual Paradigm 的一些更具体且可能较少提及的功能时,您可能会惊讶地发现您会发现什么。其中之一是:信息管理。   什么是“信息管理”? 在我们开始之前,让我们看看我们在这里处理的是什么。简而言之:处理可能来自不同来源的信息,并以目标受众可以使用的方式进行处理。这听起来很简单,虽然可能有点抽象。现在,尽管我们可以争辩说,建模过程本身也是一种信息管理形式,但这实际上不是我希望在这里讨论的方向。相反,我们将研究 Visual Paradigm 允许我们处理信息并在项目中使用它的几种不同方式。 您会注意到许多功能在您使用的 Visual Paradigm 版本的基础上变得更加广泛。 Visual Paradigm 中的信息管理 最核心的是,它适用于所有版本,Visual Paradigm 为我们提供了文本分析图。这是一种非常直接的方式,可以帮助我们启动我们的项目;基本上,它允许我们获取文本元素,例如关于某事的报告,手动提取我们想要可视化的信息片段,然后将它们作为模型元素或稍后使用的候选项目导入。 如前所述,我将忽略建模过程本身,但立即变得重要的是能够将元数据添加到我们的大多数模型元素中。 在右侧的屏幕截图中,我打开了用例图中使用的参与者模型元素的规范。项目管理选项卡允许我快速选择预先确定的规范,然后可以帮助我在以后使用它。显然也可以完全定制的规格。 当然,我们不仅限于使用预先确定的规格。“评论”和“标记值”选项卡都是提供有关元素本身的特定(自定义)信息的好地方。 报告 一旦我们收集了相当一部分信息并将其存储为元数据,我们就可以使用它来提供自定义文档来总结我们迄今为止收集的所有信息,Doc Composer和Project Publisher是一个很好的工具。 例如……使用项目管理选项卡,我可以在我的用例图中优先考虑所有用例。然后,我为 Doc composer 设置了一个自定义模板,该模板检查了我所有的用例图并总结了那些具有高优先级的图。然后,开发人员团队可以使用该信息来获得一些特定的项目方面,然后他们可以在他们的开发周期中给予更高的优先级。 这里最好的部分是这个工作流程几乎可以应用于项目中的几乎每个模型元素。 但还有更多…… ITSM ITSM 或信息技术服务管理是帮助设计、计划、交付、运营和控制 IT 服务的活动的集合,这些服务通常被公司用来为其客户提供服务。它是一种更加抽象的信息处理形式,一般来说,它使用的管理方法比技术方法更多。这也是 Visual Paradigm 支持并帮助您管理的东西。 在 Visual Paradigm 的上下文中,主要区别在于,您的项目的重点将从通常以侧面方式收集信息的情况(考虑存储为元数据的信息)转向信息的工作流。管理将成为您项目(或其当前阶段)的主要目标。 引导过程 当然有一点问题。因为你从哪里开始,如何开始?即使你决定自己分解……你可能需要开始收集信息,但任何具体的细节,也许是需要首先确定的具体目标或专业知识? 嗯,这就是 Visual Paradigm 为我们提供 Guide-Through 过程功能的原因;一种完全符合当前制定的标准的方法,它将指导您完成整个过程。尽管 Visual Paradigm 将引导您朝着正确的方向前进,但您永远不会被迫遵循该特定方法(尽管显然强烈建议您这样做)。 在这里,我开始了几个可用的 ITSM 程序之一:项目管理流程。整个生命周期由五个特定元素组成,本文的图标也简要显示: 识别——检查项目是否应该启动。 启动——指派一名经理,然后他可以定义项目的范围。 计划——制定计划以确保项目按时完成。 执行和控制——开始工作吧!所有任务都在这里解决。 收尾——记录从项目中获得的专业知识,并确保该文档得到维护。 遵循五个不同的步骤,将允许您提供有关构成该特定项目的所有活动的信息,之后这些信息将汇集在一个 Word 文档中,以形成您最终项目的基础。 在这里,我已经完成了第一步(识别),现在我准备自动生成四个文档中的一个,它将提供识别和(重新)评估我的项目的特定部分所需的所有相关信息。 独特的工作流程 此工作流程如此独特的原因在于,您将完全专注于按特定顺序提供所需信息,之后 Visual Paradigm 将收集所有部分以生成文档。 您的项目将在每个单独步骤之后保存并提交,这确保不会因侥幸事故而丢失任何数据(您基本上是在云中维护备份)。 我个人认为非常有趣的另一个方面是,即使 ITSM 工作流程的行为与 Visual Paradigm 项目中的常规任务有些分离,整个事情仍然可以轻松共存。 例如:在我完成项目管理流程后,我可以导入我收集的所有信息,并将其导入我通常的 Visual Paradigm 建模工作流程中。因为所有生成的文档都是项目本身的一部分,所以我总是可以在需要的地方添加参考。 即使该项目中存在 ITSM 工作流,我仍然可以处理项目的其他部分,例如建模或其他相关任务。我什至可以使用…continue reading →
用户故事与用例兼容吗?

用户故事与用例兼容吗?

在网上搜索,敏捷贤者认为用例和用户故事是两个不同的东西: Mike Cohn: 用户故事不是用例 Alistair Cockburn: 用户故事之于用例就像瞪羚之于凉亭 Extreme Programming.org: 用户故事与用例的目的相同,但并不相同。 用例驱动方法是需求捕获最热门的技术之一,现在有些人认为它是一种过时的旧式技术,它与许多问题相关联,导致您的团队由于用例问题而不是“敏捷” : 前期需求——试图定义前期所有方面的细节将导致大量的精力和时间的浪费,因为很多工作都需要重做。 功能分解:用例的功能性质自然导致系统在具体和抽象用例方面的功能分解,这些用例通过扩展关联并包括用例关联。 如果你在网上搜索关键词“用例 vs 用户故事”,你会发现一长串关于用例方法的缺点、问题或陷阱的文章,而与用户故事相关的好处甚至更长。 . 有趣的是,IT 行业的变化如此之快,对于人们从过去的“时尚”事物转变为现在的“较新时尚”事物的人来说甚至更快。 有趣的是,有些人喜欢以二元模式感知事物,并通过象征性地与它们相关联来追逐时尚的东西,而不是真正地实践它。有些人甚至不想让其他人知道他们仍在使用用例,或者它们可能被认为是过时的和过时的。 现在有些人把用户故事和用户案例相关的等号: 敏捷 = 用户故事或敏捷 = 用户故事 + Scrum 用户故事 = 恰到好处 & 及时 用户故事=满足用户期望和满意 用例 = 前期详细需求捕获 用例 = <<include>> + <<extends>> = 功能分解 用例是“用户输入”->“系统响应”唯一样式 用例 = 旧式和过时 作为工具供应商,我们在方法、工具和技术方面相当中立。就个人而言,我想强调一下,我是敏捷开发、用户故事和 Scrum 流程的忠实拥护者。特别是与以下概念相关的强调原则和最佳实践:   需求发现而不是需求交付 根据上述原则,在敏捷开发过程中产生了两个重要属性 准时制 正好 (我会写更多与上述原则相关的帖子,与我在 1992-1995 年的博士研究领域密切相关 - 元模型和模式转换) 现在,让我们回到主题“用例与用户故事”。好吧,重量级的敏捷贤者已经为此投了票,我是否如此固执地试图通过争论他们相似甚至相同来推翻他们的“投票”? 让我给你看一个例子来说明用户故事是否与用户案例“如此不同”: 例子 好的用户故事不仅仅是陈述。一个标准的用户故事由三个部分组成,通常称为三个 C。 每个用户故事的第一个“C”应遵循以下标准化格式: 作为[角色],我想[做某事],以便[受益] 这是要放入卡片的用户故事的最少内容。 对话是用户故事的第二个“C”的内容,代表最终用户、项目所有者和开发团队之间的讨论。在这些转换中,它记录了口头讨论,或许多其他有用的信息,如电子邮件、线框图或任何其他与项目相关的内容。 用户故事的最后一个“C”是确认,它是用于确认用户故事实施正确并成功交付的验收标准。 让我进一步详细说明如何开发用户故事的确认部分。在这里,我们使用最知名的模板 Gherkin,它采用 Given-When-Then 公式来指导用户故事验收测试的编写: (给定..和)一些上下文 (当..和)一些动作被执行 (然后..和)执行一些操作 诸如 Cucumber 和 Jbehave 测试框架之类的工具鼓励使用 Given/When/Then 模板来进行自动化测试,尽管它也可以纯粹用作启发式方法,而不管是否使用工具。 让我们收集“注册课程”用户故事的所有信息并将其放入 3C 格式: 我采用了常用的 3 Cs 格式来表示“注册课程”用户故事。同样,我还采用了最广泛使用的格式来描述用例描述所阐述的相同“注册课程”用例。我对用户故事的确认部分(最后一个 C)的步骤进行了编号,这与我在用例描述中输入的步骤编号相关联。它们是场景的相同“九步”,以不同的顺序放置在每种方法中。我相信这两种模型表示对于他们相应的圣人和追随者来说都是可以接受的。然后,问题又来了,用户故事与用户案例非常相似,但它们是不同的,还是步骤的顺序导致了对用例方法的各种批评? 语义等价但含义不同? 让我们调查一下建模领域是否有类似的案例,以便与这里的情况进行比较,或者它可能有助于我们对“用户故事与用例”进行投票,但不要盲目跟风或重复圣人如鹦鹉般的说道。 示例:语义等价…continue reading →

有没有最好的软件开发方法?

“工欲善其事,必先利其器” 《论语·魏灵公》  “工欲善其事,必有器” 《论语》 软件方法是使用选定的过程技术来提高软件开发工作质量的实践,从而减少缺陷,从而最终提供更短的交付时间和更好的价值。一种软件方法通常被认为比其他任何方法都好,但总是无休止地争论不休。我必须说,没有一种最好的开发方法,不同的方法最适合不同的项目环境。什么是最好的取决于方法是为谁,在什么情况下,为了什么目的,等等;说没有一种方法最适合软件开发人员,也就是说不同的方法最适合不同的团队或不同的项目性质。 Grady Booch 说: “如果你想建造一个狗屋,你几乎可以从一堆木材、一些钉子​​和一些基本工具开始,比如锤子、锯子和卷尺。几个小时后,你很可能最终会得到一个功能齐全的狗屋……如果你想建造一座高层办公楼,你会想要进行广泛的规划……你将只是一个更大的群体的一部分负责开发和部署建筑物,因此团队将需要各种蓝图和模型来相互沟通……” 您会为小型 Web 应用程序和 NASA 太空探测器采用相同的方法吗?可能不会。你会在六人团队中采取与六十人团队相同的方法吗?再一次,可能不会。正如 Scott Amber 所指出的,不同的情况显然需要不同的方法。软件开发没有一刀切的解决方案,事实上,设计人员需要拥有广泛的工具供他们使用,了解每种工具的优缺点,并能够快速决定最合适的工具在给定上下文的理想工作流中应用。continue reading →