我的问题涉及具有UML / UTP经验的软件架构师。
简介： 我们目前处于新项目的开始阶段，其中编写了带有嵌入式软件的硬件的文档。我负责GUI开发。作为起点，使用先前的模型。它的GUI作为第一个信息呈现给我，并对其进行了一些计划的修改。
虽然我有超过15年的软件开发经验，但我很少参与项目的开始阶段，因为我是一名咨询顾问。当项目耗尽时间时，通常会打电话给咨询者......
我认为从功能规范的并行开始测试文档很重要，我考虑使用UML来描述功能部分。对于测试，我想到模型驱动的测试和使用UTP（UML测试配置文件）。
详细信息： 在我们的系统中，存在三种类型的用户（演员）：电厂技术员，调试技术员和系统专家。 GUI主要用于 1.观察价值观并改变指数值 2.进行设备调试（调试模式） 3.安装新软件或进行系统维护（专家模式）
只有处于调试阶段的处方。在当前九个菜单及其子菜单中读取和更改值没有详细描述，因为它或多或少是直截了当的。
我的问题： 是在这样的项目中推荐使用UML / UTP，以及扩展到什么程度？是否可以为每个简单的菜单访问用例图？我不想被UML发烧（见Death by UML Fever ）
答案 0 :(得分：0)
一般来说，我会说，除非组织已经使用UML，否则你会想要引入它。用例是一个很好的起点（用例图带有很少的信息，因此很容易掌握），但即便如此，咬掉的东西也比你咀嚼的要容易得多。
任何类型的文档，无论是纯文本还是UML图表，都必须是目标受众可读的。所以你需要确保那些将阅读你的图表的人都知道足够的UML来理解它们。如果他们都是软件工程师不应该是一个问题，但如果他们中的一些是用户代表，经理，销售或其他任何可能更棘手的。
如果您正在使用某种程度的正式流程和/或受控工具套件，您还需要考虑这一点：您的模型如何适应已建立的流程，以及您的工具如何适应工具链？
UML非常有用，但我当然不会尝试自己介绍它。如果您决定采用这种方式，请确保您拥有管理支持。