周星
More options Mar 1, 10:11 pm
谢谢潘老师。
另一个问题：业务建模时，如果业务用例实现涉及到的组织内部业务工人和业务实体很多，如果有效的处理？例如修理飞机是工厂的业务用例，如果分析该业务用例的业务 流程，直接将具体岗位作为业务工人，则要定义太多的业务工人，而且整个业务序列图上的对象和消息太多了，陷入分析瘫痪的境地，如何适当提升抽象级别来解决这个问 题？将部门作为业务工人的话，又无法得出系统用例，因为部门作为一个整体使用系统好像是没有意义的，使用系统的一定是具体的岗位。
UMLChina
More options Mar 2, 8:33 am
先分到部门，部门内再分配是可以的，不过，现实中很多组织的部门责任划分并不合理，所以建议还是要先具体到岗位，这样可以通过业务序列图的结构观察，自下而上地 推导出部门的责任划分。如果步骤很多，可以把业务流程分为若干片段，一个用例下面画多张序列图，这样一张序列图上出现的对象个数可以把握。
可以用业务工人代表部门，采用聚合来表达，部门业务工人聚合各个岗位，岗位之间有上下级关系。也可以给类添加一个新的构造型 （stereotype），例如：部门。EA 中在Setting-->UML 中设置。业务工人、业务实体。。。。。其实都是类的构造型。
需要画各部门分工的序列图，此图上最小颗粒是部门，业务实体可以不画。然后，画各部门的大责任在内部如何分配的序列图
jim1997
More options Mar 6, 12:47 pm
潘老师，各位朋友：
业务建模该采用什么工具方法，我觉得是值得先考虑的。在我的实践中，有这样一种做法：对于有一个柜台提供服务类业务，我们可以采用UML 来做业 务建模，而在如制造业、项目管理类企业信息化业务，在业务流程建模上不适合采用UML 的顺序图。这一类业务，往往不会强调某一个活动是否一定由一个角色来执行，换一个角色执行往往会照呆转得动，过多的考虑角色，会偏离了业务本质的关注点。也就会出现周大侠所说的分析瘫痪。
在实际的业务建模中，可以穿插的使用流程图（活动图、或者Visio 画的）、框架图（描述一个整体视角，业务组成、产品规划）、关系图（描述重要的业务组织、业务实体、主要关注对象间的关系，形式不限）和机制图（描述业务系统的运行机制）。业务建模一定不能偏离业务，不必拘泥于具体形式。如果能将很深的业务问题比喻成日常的、相关涉众都熟悉的事物，那就是最高境界了。
UML 在用于.理解新的需求（新行业、已知行业的新领域等）和向技术人员详细描述需求关系等时是很有用的，但如果面向客户的话，估计会走偏 了。
一定心得，与各位分享。
同望科技 渔歌
UMLChina
More options Mar 7, 9:47 pm
总的思想：需求要具体，设计要抽象。
从"系统提供查看监控记录功能"到"科长-->查看监控记录"，多出这个小人是很有意义的，可以参见附件我写的《这个小人不简单》。
业务流程如何描述，并没有标准答案，只要选择了从涉众的视角观察而不是开发人员的视角，得到的就是正确的。要警惕的是：常会有开发团队由于实现一个系统时可复用 组件的比例较高（例如拿某个工作流引擎配置一下就可以），然后做业务建模时就描述得很抽象。我的观点是，业务建模、需求还是要具体化、场景化。抽象、复用、本质 这些概念属于设计的思维。
UML 仅是开发团队内的统一语言，是严谨的"模型"。和涉众通过灵活的"视图"交流"涉众利益"
周星
More options Mar 7, 11:27 pm
感谢潘老师的答疑和渔歌的说明。
我这里现在有这么一个项目，关于面向飞机维修业务的PDM项目，相关情况如下：
1、业务概况
飞机修理业务是为飞机所有者/运营商提供的一种服务。客户飞机使用到一定时限后，需要进行相应级别的修理，以恢复其固有可靠性，飞机维修企业就是提供这种修理服务的。（类似于汽车每若干公里或时间就要进行保养、中间检查、大修等）。
修理有以下特点:
1)修理对象是客户资产；
2)修理既有固定的工作内容，也有视具体问题而定的工作内容；
3)修理涉及到飞机的分解和装配；
3)修理需要消耗人工、物料等资源，并根据具体内容使用相关设备设施，这些就是修理消耗的成本；
4)修理过程中存在大量的检验活动，既有特定工艺过程的检验，也有对具体修理结果的检验；
5）修理具体工作内容的确定,需要从设计制造厂商得到必要的产品资料，如产品图样、修理要求等，作为制定修理方案的依据。
2、修理技术工作（本项目涉及的业务范围）
修理业务在技术方面，需要制定修理方案，确定不同产品不同等级的修理工作范围、标准和具体方法及其资源需求，为修理业务实施提供技术依据，这是修理技术工作的主 要职责之一；第二是解决修理过程的各类技术问题；三是研发，即研究形成新产品的修理方案和修理标准。
3、项目范围与目标
本项目即面向修理技术工作，为修理技术工作提供支持，主要目的有以下几点：
1）改进为修理实施提供技术工艺依据的形式，从非结构化的文档转变为结构化的数据，以便修理生产管理系统（生产计划和执行）、修理资源管理系统（物料、设备、人 力资源、财务等）能够更好的利用，目前生产、物料、设备、人员等管理过程所需的依据性数据，无法与技术依据保持高度一致；
2）保证外部技术变更（如产品设计变更、技术状态变化、改装升级等）更加及时、准确、完整的落实到具体修理过程中；
3）更加便于修理操作者使用，并保持状态适用；
4）现场技术问题处理更加及时，并便于跟踪处理进展，与生产进度相关联；
4、计划的做法
针对该项目，我们作为甲方，现阶段，主要是期望把项目的需求尽可能描述清楚，即符合我们企业的要求，又利于有意向参与的公司更准确的把握我们的需求、项目的范围 与风险，从而在双方合作之前就尽量消除由于项目目标、范围不明确，工作量估算偏差大等风险。现在我们准备按一下思路工作，请潘老师看看是否合适，以及还应注意些什么。
1、梳理修理业务框架
以我们企业为分析对象，识别对客户提供的主要服务，即业务用例，然后分析业务用例实现流程，识别对技术系统（指企业的技术职能系统相关部门）的要求，即技术系统 的职责，从而确定以技术系统作为分析对象，其对企业内部其他部门提供的服务，从而确定技术系统的所有业务用例；
2、分析技术类业务流程
逐一分析技术系统业务用例实现，识别改进点，确定改进后流程，进而确定对要开发实施PDM 系统的系统用例；
3、分析系统用例，确定需求
针对业务流程中的系统用例，详细分析确定其系统需求（用例场景）。
4、补充其他非功能性需求
上述工作成果作为招标软件需求协议，用以招标。
按上述思路执行，感觉还有一下困难。
1、分析工厂的业务用例确定对技术系统要求时，不好确定是否完整。例如，修理飞机是工厂对客户的一个业务用例，但实际业务中，包括修理计划管理和具体修理过程。 业务用例实现中可以比较容易描述出具体修理过程（虽然涉及岗位很多），但计划类活动如何体现？
2、分析技术系统的业务用例实现时，同样存在上述问题，如研发，同样存在计划性工作和具体流程性工作，后者好分析，前者又不知道如何处理了。
3、系统用例的识别，涉及对现有流程的分析和改进，而这如果在招标前就已确定，无形中就限定了开发商的能动性，而且也有可能不切实际而且未必最好，但不确定改进 ，系统用例又无法识别，也就得不出对系统的需求，不利于在招标时尽量清晰明了。
以上问题，罗嗦了很多，还请指教。
UMLChina
More options Mar 10, 5:07 pm
感谢周星非常具体地提供项目素材来讨论，希望大家方便的话，也多多提供自己的具体项目。
"1. 业务概况"勾勒出了飞机修理领域的核心概念，这些核心概念可以进一步采用某种领域建模手段（类图、带彩色建模架构型的类图、ER图…都可以）精确描述，帮助深入 理解领域，也作为各个项目的参考。
"3. 项目范围和目标"相当于愿景，此处需要进一步理清各个形容词的度量指标。"更好的利用"、"高度一致"、"更加及时准确完整"、"便于修理"….
"4.计划的做法"
*步骤基本正确。
*组织的业务用例该是哪些就是哪些，不需要花太多时间去识别。"技术系统的所有业务用例"说法不正确。
*类似修理计划的流程，有一种做法是"管理型业务用例"，把它们归到老板或领导针对组织的管理目标的业务用例，例如"领导-->节约修理成本"，但我认为这样不妥当，很容易被滥用，变成和愿景差不多。推荐做法：还是把它放在"修理飞机"下，另外画序列图。
*"业务用例"是组织对组织的服务（或价值）。为了完成一个"价值"，两个组织的系统（人肉系统，电脑系统，时间系统）可以在很多发生频率不同的场景中发生很多次交互。在有的场景中，甚至是两个组织之间的电脑系统交互，人肉系统不参与。
*可以优先描述愿景相关的场景，基本能判断不相关的可以先不描述。