hshs(69****7) 09:42:45
潘老师，我这里有人有个奇葩的需求，您见多识管，看看有人或软件实现没？
有人是字符控，不愿意用任何图形化工具，所以匪夷所思的想让用例图，时序图用文本来表示
类似一些用 文本字符拼成一个图像，
潘加宇(3504847) 09:45:32
bbs时代都这样，应该很多，你看看网上有没有共享的源码
潘加宇(3504847) 09:46:14
如果仅仅是UML就更好办了
潘加宇(3504847) 09:46:31
看看我们的工具列表
hshs(69****7) 09:47:24
您的意思您的工具列表中，有这样一款软件可以将UML图转换成文本？
潘加宇(3504847) 09:47:56
很多
hshs(69****7) 09:48:25
ea可以么？
潘加宇(3504847) 09:48:57
可能是文本好做版本控制吧
潘加宇(3504847) 09:49:43
但这个人是什么人，这个要求不合理
阿弥陀佛(17****28) 09:50:14
plantuml 用字符写UML，直观且支持最多种图。
hshs(69****7) 09:50:34
一个是版本控制，一个是文本是最容易被share
hshs(69****7) 09:50:42
太感谢了
潘加宇(3504847) 09:51:21
模型本身就是文本，但这个文本不是象形模拟图形的文本，而是背后的语义
hshs(69****7) 09:52:20
潘老师说的我理解，就像网页 呈现的图像，传输可以看成base64流文本
潘加宇(3504847) 09:54:37
还是用好ea吧，不会要学
EliteQ(8732860) 10:02:35
EA 的模型统统都是 XML 啊，所谓的版本管理，也是对这些 XML 进行管理
阿弥陀佛(17****28) 10:15:29
我用plantUML画的图，你问他看看是不是想要我这样？
通过代码的参数设置，可以将所有引用变成"引用"或嵌入一张图中。不用考虑排版布局，集中精力写逻辑就好了。
潘加宇(3504847) 10:33:13
序列图消息是"A请求B做某事"，图上好像不对的
潘加宇(3504847) 10:34:56
另外，没有确定研究的边界，图上应该都是类(相当于边界是整个宇宙)
阿弥陀佛(17****28) 12:11:44
消息没有完全按 请求做事的格式写，因为比如 施工招标 确定施工单位，后面基本不会招标单位的事，就没考虑画招标单位了；而且业务领域的人和资料都习惯以"A做某事，（结果接收者B） "这样来描述事情，在整理资料时为沟通方便我不会特意将"进场通知"写成"进场"，"XX申报"写成"XX受理"/"提交XX申报"，或将"XX申请"写成"请求XX"；它们这些消息都对应特定业务事件名称、文档、表格，不按业务上习惯的名称，既要向业务相关人员重新解释，并且要找对应资料时更困难。
研究边界？？
这个是还没确定如何做系统，业主自己有何业务职责他自己也不完全清楚，牵涉的对象有哪些也都还不清楚，是我们想先理清整个相关业务，然后看能不能找业主谈做系统，商讨系统要考虑哪些对象。（这个内部开过几次讨论会，后面也没再继续了）
图上应该是类？
我觉得这还只是单纯描述现实事务的某个处理过程，我觉得还要考虑是否将当前的职责抽象，按角色重新调整分配后再建类。比如当前业务流程中某个人可能会实际上承担着多个角色的职责，但这些职责随时可能会分离、变更或合并。即建模过程是： 业务参与者=>业务角色（类） => ……
潘加宇(3504847) 12:21:49
建模不是为了"和涉众交流"，就像医生给病人做核磁共振扫描不是为了让患者看懂谱图。
业主组织就是研究对象
类指的是"研究对象内部的基本组成单元"
可以再看看《软件方法》
阿弥陀佛(17****28) 13:22:22
是自己内部交流，一方面懂业务的不是搞电脑的，他们整理的资料很多很模糊有歧义甚至是错的，我只能先用技术方法重新整理，然后对着图跟他们重新表述，让他们检查是否是这样的意思，哪些他们可能错了实际上是这样的；如果不用这种图与他们交流，又会有很多理解偏差的地方难以发现。
潘老师有没好的方法以保证沟通不出现理解偏差？
业主有项目管理的职责，但业主不知如何管，要管哪些资料，有哪些人要使用系统（业主、监理、建设单位肯定要用，质监等与业主平级的暂时不用，但可能可考虑做系统对接，施工单位、包工头那些则很难说，这些都是系统要面对研究的；这并不是企业内部的系统，是一个项目多方）。很多资料并不是业主内部产生，或别人提交给他们。需要管理哪些资料他们也不会帮我们去理清楚。我们只能自己找标准规范理解业务后再与让领导与业主商讨。
或许可以说业主的愿景其实就是"现在别烦我，我不想管，你帮我想做决定；但系统上线后我要什么就得有什么"。类似这种自己不熟悉业务，还要代业主提出需求的，各位有没好的经验可借鉴？
另外，A请求B做某事 这种消息表示，消息箭头指向自己的就是自己的职责（被动的，由别人发起的）。但业务上的职责表述习惯与这种说法并不一致，业务上的职责更强调发起方，比如我上面的 XX申报，业务上通常强调施工单位有申报的职责，而不提监理单位有审批的职责；即很多业务是强调发起方的，业务没做，是要由*发起方承担责任*的；业务上是担心没去做事（相当于方法函数的调用）如何做不是业务管理者关心的，我们写代码的才会关心的是怎么实现（方法函数的实现）。A请求B做事的消息表述 体现不出的申报职责，而强调审批职责；我觉得 A做某事（结果接收者B）的事件表述，与 A->用例 的表述方式更接近，业务流程改造后，将业务事件转成用例名会更自然。潘老师，这样做会后面有什么麻烦不？
潘加宇(3504847) 13:58:38
1,2两点可以再复习软件方法和以往答疑记录
第3点。施工单位有申报的责任，监理有审批的责任，申报箭头指向施工单位，审批箭头指向监理单位。
申报、审批都是做事。施工单位要做出一份优秀的申报，有很多学问，监理单位要合理审批申报材料，也有很多学问。
至于以后系统用例之类，你现在还在研究组织之间的关系呢，连组织内部都没研究
阿弥陀佛(17****28) 14:49:50
完整的申报确实可以再分成 准备申报资料 和 审批 两方面，只是在这种初期整理资料时我都不会这样细分，只当成一个整体事件看待。如果我要考虑到申报如何做时才会再去细分，这还有可能涉及到向包工头收集申报资料，找人内部审核等事情；类似于审批包含于申报事件的后面一段，并不是主动行为，很多被动行为在细化时我才有可能发现，开始我是不考虑的。
潘加宇(3504847) 15:59:48
责任合并的话，单位也要合并了