所在位置:答疑 - 内容   
有人是字符控,不愿意用任何图形化工具,所以匪夷所思的想让用例图,时序图用文本来表示
 

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
责任合并的话,单位也要合并了