《统一建模语言UML课件.ppt》由会员分享，可在线阅读，更多相关《统一建模语言UML课件.ppt（146页珍藏版）》请在三一办公上搜索。
1、统一建模语言UML,电力营销系统案例获取需求,定义边界,对于全新的项目，分析员首先要做的工作就是定义边界。边界可大可小，很多时候依靠建模者的经验和意识。定义边界的目的是为我们确定一个分析的起点。,定义边界,如何定义边界？,通过前景文档中的业务目标来定义边界？还是通过业务模块划分的方式来定义边界？,通过业务目标定义边界,电力营销系统业务目标一：“为用电客户提供业务办理自动化服务，提高办事效率，方便客户，为客户提高更好的服务”分析：此业务目标为谁服务？用电客户得到一个用电客户服务边界,用电客户服务边界,启示,各业务管理部门位于边界以内，是业务工人，他们的期望可以暂且不考虑。疑问：前述的各种XXX管
2、理功能到哪里去了？释疑：每个业务目标都会有一个边界每个边界有不同的参与者在不同的边界内将推导出不同的业务用例。,内部管理目标边界,进一步讨论之一,上述划分边界的结果与以前所谓划分子系统有什么差别？仅从名称上看，二者非常相似。仔细考虑可以发现诸多不同：划分依据：子系统划分没有明确的依据，没有明确的判断标准来决定何种划分方式是合理的。业务目标划分方式有着明确的依据。针对每个业务目标，可以明确决定系统内外，明确决定哪些涉众与此业务目标利益相关，进而得到若干业务用例。,进一步讨论之二,大部分边界划分的方式是从谁使用系统这个角度来划分的。这和从业务目标角度划分有何区别？,按这种方式划分存在若干问题：无法
3、获得明确的业务用例。无法知道这些涉众对边界的真实目的是什么，只能盲目的将涉众所有的期望堆积在边界里。面对诸多的用例，如何进行组织？如何分包？,按这种方式划分存在若干问题：导致业务用例过多，关联关系混乱。无法区分业务主角和业务工人。会出现非常多的用例在边界里，如果都与边界外的涉众关联上，业务用例视图将混乱一片。,进一步讨论之三,是否任何时候以业务目标为依据来划分边界都是有效的呢？当待开发的是计算密集型或者控制密集型系统时，似乎难以找到明确的业务目标，即使找到，数量也很少，此时使用业务目标为依据划分边界似乎很别扭。例如：玩家玩游戏,其实，对于非交互密集型系统，即使没有明确的业务目标，也有明确的功能
4、目标，即系统特性，可以以这些系统特性为边界，得到不同的主角与用例：例如：控制系统、游戏引擎、声效等控制系统为边界，键盘、鼠标、手柄发出前进动作、发出射击动作,发现主角,得到涉众分析报告，已经定义了边界，我们可以据此寻找业务主角。主角：代表了涉众利益，站在边界外，直接与边界代表的系统交互，对系统有明确的要求，并从系统中获得明确的结果。,发现主角,是否所有的涉众都会成为业务主角？只有那些直接与系统交互的涉众才能成为业务主角。,发现主角用电客户服务边界,在此边界外有两个涉众：用电客户、银行。用电客户涉众主角分析情形一：用电客户不直接使用系统，而是通过到营业大厅填写纸面申请，由营业大厅业务员代为填写电
5、子申请单并提交。用电客户不直接与边界所代表的系统交互，营业大厅业务员成为代表涉众利益的业务主角。,发现主角用电客户服务边界,情形二：业务范围包括网上办理业务，用电客户可以直接使用系统进行办理业务。用电客户本身就是业务主角。情形三：一些大用电客户，供电企业设置了专职检查和服务联络人员为其专门服务，这些专职人员可以直接为大客户办理业务。专职检查人员成为代表涉众利益的主角。,发现主角用电客户服务边界,银行涉众主角分析前述分析中，已经取消了实时联网收费的期望，仅保留离线收费，每日结算收费方式。即银行的收费行为与系统之间不会有直接的交互。每日会有某位营业出纳从银行处获得每日收费记录，并将其导入系统。此时
6、，营业出纳将代表银行成为系统的一个业务主角。,发现主角内部管理业务边界,依据前面的涉众分析报告，内部管理业务边界之外的涉众有：营业财务管理部门、电表抄表部门、电费管理部门、资产管理部门、现场施工部门、业务服务部门、用电检查部门。,发现主角内部管理业务边界,营业财务管理部门涉众主角分析该部门设置了营业会计、营业出纳、营业收费员。这三个角色会按照财会准则各自负责自己的部份，保障财产安全。财务管理部门设有财务主任，负责财务工作的安排、人员工作情况的评估、业务规则的制定。代表业务目标是规范化和管理职能，行使了内部管理职能的业务主角是：财务主任。,发现主角内部管理业务边界,电表抄表部门涉众主角分析该部门
7、大部分工作人员抄表工，携带抄表机或抄表单外出工作，他们不直接使用系统，而是将抄回的结果交给内勤人员，有内勤代他们将抄表结果导入或者录入计算机。抄表工作由抄表班长按片区、按变压器线路等将工作分配给抄表工。其中抄表班长行使了内部管理职能，是内部管理业务边界的业务主角。,发现主角内部管理业务边界,电费管理部门涉众主角分析该部门负责计算电费，由发行员来完成。对于一些特殊客户和特殊情况的电费计算规则的改变，必须通过电费班长确认签字。行使了内部管理职能，成为内容管理业务边界业务主角的是：电费班长。,发现主角内部管理业务边界,资产管理部门涉众主角分析该部门负责管理供电设备，资产管理员负责管理设备的整个生命周
8、期。资产出库入库前需要校修人员负责校修。资产运行中，需要由资产班长制定轮换计划，资产运行一段时间后按计划轮换资产。此处业务主角：资产班长。,发现主角内部管理业务边界,业务服务部门涉众主角分析该部门由业务员、业务收费员、业务班长组成。业务员受理客户用电申请；业务收费员负责收取业务费用；业务班长负责安排工作，评估业务员服务水平，审批业务。此处业务主角：业务班长,发现主角内部管理业务边界,用电检查部门涉众主角分析该部门定期按计划对用电安全进行检查。其中用电普查、专项检查由检查班长制定计划，分派检查员进行现场检查，检查结果由检查内勤录入计算机。专职检查员维护自己所负责的用电单位的资料，自行安排检查计划
9、，但必须通过检查班长审批。此处业务主角：检查班长,发现主角内部管理业务边界,整个电力营销工作，即以上职能部门工作由用电主任统一管理，制定营销规则、进行人事任免、确定岗位职责。此处业务主角：用电主任,发现主角内部管理业务边界,各职能部门班长负责各自部门人员的职责、权限等，但是希望由信息中心的系统管理员代为行使其人员和权限管理职责。此处系统管理员将代表各职能部门负责人和用电主任行使人事管理职责，成为业务主角。,用电检查和管理边界业务主角,营业财务管理边界,进一步讨论之一,如何理解业务主角与涉众之间的关系？业务主角与涉众的区别：业务主角与系统直接交互，涉众未必直接与系统进行交互。如果涉众不直接与系统
10、交互，就必须找到代替他行使利益的另一个角色，可以与涉众毫无关系，二者之间是一种代理关系。,进一步讨论之一,代理关系不同于继承。继承表示子类拥有父类所有的非私有职责，代理是拥有被代理者指定的部份职责。不同于实现实现表示实现类是超类的一种实例化，超类可以拥有多种实现，但每种实现都可以上溯到超类。但代理者虽然可以有多个代理，但多个代理可以位于完全不同的继承树上，不一定能上溯为被代理者的类型。,进一步讨论之一,寻找业务主角过程中，涉众分析报告是重要信息来源，一般业务主角可以从涉众分析中获得。业务主角一旦决定被代理哪个涉众，就会收到涉众期望的制约。业务主角不能逾越或改变涉众期望，但是能决定实现涉众期望的
11、过程。,进一步讨论之二,业务主角所代表的涉众期望是否可以一一映射？业务主角是否一定要代表涉众利益？有时要找到业务主角所代表的涉众期望是困难的，它不明显。例如系统管理员清楚日志、优化数据等。对系统分析员来说也不是一定要为所有的业务主角都找到其所代表的涉众利益。,进一步讨论之二,为业务主角找到所代表的涉众利益的理由：业务主角不代理任何涉众理由，业务主角的主张就缺乏支持。业务主角不代表任何涉众利益，其存在性值得怀疑。,进一步讨论之三,业务工人可能是流程的实际执行者，但他们却无权对系统提出要求，如何理解？业务主角是边界外的，只有边界外的事物才有权向边界代表的系统提出要求。由内部员工制定的不遵循客户期望
12、的规则，通常是霸王条款。但是也不能否认内部工作人员的意见，他们最终决定工作的流程。,进一步讨论之四,当有业务主角找不到对应边界，或者业务主角的一些要求无处放置时，该怎么办？边界代表了某业务目标，除非业务主角确实参与并贡献于该业务目标，否则不应当成为该边界的业务主角与业务目标无关的要求也不应当在该边界中体现出来。应重新检查涉众分析、问题领域定义。,进一步讨论之五,业务主角与系统参与者是一致的吗？业务主角区别于系统参与者。系统参与者是系统的实际操作者，通常在系统中都有ID，系统会为其建立会话，其有存在范围和生命周期，在系统中是需要编程实现的。业务主角是用于分析业务的，可能不会转化为一个参与者。业务
13、主角不应当被过分的抽象化和虚拟化，应该能够映射到现实中的敢为设置、工作职责说明等。,获取业务用例,经过上述分析，系统的边界已经确定，主角也确定了，在此基础上可以进行业务用例的获取。,获取业务用例,有很多方法：可以从岗位手册、业务流程指南、职务说明等一系列文件中获得；可以从涉众分析中获得；也可以从业务主角访谈中获得。,获取业务用例,可以通过下列问题引导业务主角代表说出业务需求：您对系统有什么期望？您打算在这个系统里做些什么事情？您做这件事情的目的是什么？您做完这件事希望有什么样的结果？,例一：业务员将代表用电客户提出业务需求,听第一段对话，并思考：这里业务员说的是系统的功能需求吗？业务员代表客户
14、提出什么期望了吗？,例一：业务员将代表用电客户提出业务需求,点评：客户谈系统期望时，通常不是业务需求，更多的会谈及他们希望系统能帮助他们做什么，从中找出明确的需求并不容易。业务员代表客户提出问题，但其是系统直接使用者，不可避免会谈到对他们有理的一些期望，应判别这些期望是否与用户利益有冲突。,例一：业务员将代表用电客户提出业务需求,听第二段对话，并思考分析员打断业务员说话的原因是什么？点评：初步了解业务时，要防止陷入过深的细节，应当引导客户先从独立的业务模块开始讲起。,例一：业务员将代表用电客户提出业务需求,请听第三段对话，并思考为什么分析员要业务员谈谈业务的目的，而不用将业务是如何一步步办理的
15、？点评：让业务员谈某一项业务的目的，可以帮助分析员判断用例是否合理，是否这些业务能作为一个业务用例。例如：此处低压、高压、批量等业务只能看作同一个业务用例。是用例规约文档中前置条件的重要来源。,例一：业务员将代表用电客户提出业务需求,请听第四段对话，并思考为什么要让客户说明每项业务的结果？点评：可以帮助分析员分析用例，这是用例规约文档中后置条件的重要来源。,用电客户服务业务概要视图,例二：用电主任谈内部管理需求,案例中有一个内部管理业务边界，业务目标是规范供电企业的内部管理，提高工作效率和管理效能。,例二：用电主任谈内部管理需求,请听第一段对话，并思考：你能从用电主任的谈话中归纳出业务目的吗？
16、能从这段对话中归纳出相关的业务规则吗？,例二：用电主任谈内部管理需求,点评：业务员访谈的例子没有涉及什么业务目标，这段对话中存在明显的业务目的，归纳为：监控业务流程，可作为备选业务用例。为什么不是记录流程信息呢？这涉及到谁来记录，业务主角是谁。这里应该是计算机来记录，业务建模阶段一般不予考虑；即使考虑，它也是在边界以内的，所以记录流程信息不是合理的业务用例。,例二：用电主任谈内部管理需求,为什么不是查询和统计流程信息呢？这涉及得到业务主角的业务目的。获取业务用例时，不应该从谁做了什么为出发点，而应当从谁为了什么而做什么来考虑。如果没能找到真正的目的，可能将紧密管理的业务分割开来，造成信息链断裂
17、。例如：记录流程信息查询和统计流程信息，如果各自分开设计实现，可能无法满足用户要求。,例二：用电主任谈内部管理需求,这个例子中可以得到一些业务规则：记录业务流程数据、控制时限、安排工作、警报等为什么这些是业务规则，而不是业务用例呢？业务用例即所谓功能需求，是指如果缺少它，业务目标就无法达成。上述要点中，哪怕不做某一些，业务目标也能完成，只是质量不高，不顺利。这些要点只是用来辅助和约束业务目标的，因此应该是业务规则。,例二：用电主任谈内部管理需求,请听第二段对话，并思考：分析员是如何引导客户说出需求的？分析员如何帮助客户认识哪些工作由计算机完成，哪些由人工完成？,例二：用电主任谈内部管理需求,点
18、评：客户并不能了解用例是什么，也不能过多的期望用户能直接说出用例，很多时候需要系统分析员来归纳和总结用户的意思，并向用户求得认可。用户有时无法了解什么是计算机能做的，什么是不能做的，分析员可以适时的提出。,例二：用电主任谈内部管理需求,分析员在获取业务用例前，应当能对客户业务有大致的了解，这样才能引导客户将完整的需求讲出来，避免用户想当然而掩盖了一些需求。,内部管理业务概要视图,例三：业务主角角度展示业务用例,从前面分析中，得到了从业务目标的整体角度展示业务构成。这种展示方法难以让跨边界的业务主角全面明白他们所参与的用例。为了能把业务说清楚，并让业务主角代表清楚他在整个系统理究竟做了些什么，通
19、常需一份视图，将参与了多个业务边界的业务主角的所有业务用例集中在一个视图中展示出来。,业务主角业务用例视图,进一步讨论之一,以上例子是通过客户访谈行使得到业务用例的，如果有些系统的建设不具备访谈条件，例如没有访谈对象，那如何获取用例？任何对象一定有消费者，只要有消费者就会有需求。划分了业务边界，就一定有站在边界外的消费者。可以使用CRC（类职责协作）方法来进行分析。,进一步讨论之二,业务用例找到了，是不是列出了就行了？列出来是不够的，还要从不同的角度应用不同的视图将它们展现出来。,进一步讨论之三,业务用例的获取什么时候结束？只要感觉到把客户的业务弄清楚了就可以考虑结束，不必等到将每件事都定义清
20、楚。业务用例的意义在于能够帮助分析人员在短时间内从结构上、整体上了解业务构成，只要整体信息把握了，就可以考虑停止更深入的获取业务用例。,业务建模,要建设一个高质量的系统，要从建立准确、清晰、高效和强壮的业务模型开始。,业务模型,完整的业务模型包括：业务用例视图业务用例场景业务用例规约业务规则业务对象模型业务用例实现视图业务用例实现场景包图,业务用例场景,用于描述该业务用例在该业务的实际过程中是如何做的。通常：强调参与该业务的各参与者的职责和活动，可以选择活动图；强调该业务的完成时间顺序，可选择时序图；强调参与该业务的各参与者之间的交互过程，可选择协作图。,用活动图描述业务用例场景,侧重于描述参
21、与业务的各个参与者在该业务中所执行的活动。适合分析参与者的职责，且有利于将业务用例分解成为更小的单元，为获得概念用例、系统用例带来好处。,用活动图描述业务用例场景,通常将参与者和业务工人作为活动图的泳道，将参与者和业务工人所完成的工作作为活动，依据实际业务流程中的执行顺序将这些活动连接起来，形成业务用例场景。,用活动图描述业务用例场景,有两个基本要求：必须忠于真实业务。描述业务用例场景时，不能试图进行抽象、优化，必须和客户认可的实际执行过程一致。一个场景只能描述业务的一种执行方式。不要在一个场景里把业务的所有内容都包括进来。,低压用电申请业务用例场景活动图,高压用电申请业务用例场景活动图,问题
22、：,高压和低压电用户仅在设计、设计审查两个活动有所不同，此处为什么要设计成两个场景，而不设计为同一个场景中的不同分支呢？,如何区分场景分支和另一个场景？,如果客户在其业务理解上，将看上去不同的业务执行过程看作是同一个概念，应考虑将这些不同的活动作为同一个场景的多个分支，反之则应当单独作为一个场景。如果看上去不同的业务执行过程实际上所处理的内容是一样的，应当将不同的活动作为一个场景的多个分支，反之则应当单独作为一个场景。,例如：高、低压用电申请场景,低压申请和高压申请是通过不同的人员来接待办理的，虽然二者执行的活动差不多，但实际上所填写的表单差别很大，高压用户要填写的内容多得多。因此将其分为两个
23、场景,例如：邮局寄包裹场景,客户可以选择购买邮局纸箱来包装包裹，也可以从自己家里带去。如果选择购买邮局的纸箱，业务过程就会多出到包装柜台包装的活动。这种情形应该视为同一个场景的两个分支还是两个不同的场景呢？,提示：邮局不会认为购买和自带是两种不同的邮寄方式。两种方式下，邮局不会区别对待包裹、处理内容、填写的单子也不会不同。可以看作同一场景中的不同分支。,例如：交纳手机话费场景,用户可以到银行，由银行代理收取；也可以通过网络交易平台，用网络支付卡交纳费用。上述两种缴费方式要看作不同的场景还是同一场景中的不同分支？,提示：银行缴费和网络缴费不是同一概念。两种缴费方式处理的内容、步骤、填写的单据是不
24、同的。应看作不同的业务场景。,用活动图描述用例场景,好处：活动图可以理解为通常意义上的业务流程图，可以非常直观的描述客户的业务流程，这对与客户交流来说是非常好的工具。从活动图中也可以得到许多关键概念：职责、活动。这些概念将有益于日后的概念用例、系统用例、业务架构建模。,用时序图描述业务用例场景,同样是将业务主角和业务工人作为对象来绘制。与活动图的区别：活动图强调职责，活动是主要内容，表达了业务主角或者业务工人做什么；时序图强调顺序，消息是主要内容，表达了业务主角或者业务工人之间传递的是什么。,低压用电申请业务用例场景时序图,用时序图描述业务用例场景,其中传递的消息一般带有业务数据。与传统的DF
25、D图有异曲同工之妙。此时时序图中的消息粒度比较粗，只能帮助我们了解业务，达不到分析数据的详细程度。,用协作图描述业务用例场景,更容易看出业务主角或业务工人与其他人之间的交互。注意分析图中与多个对象进行交互的角色。,低压用电申请业务用例场景协作图,关于如何选择视图的建议,组成执行团队，明确职责，规定每个角色的分工和要完成的工作时，选择活动图比较合适。强调行动步骤，在方案中要求每一步都按照预期的顺序来执行，此时选择时序图比较合适。向每个参与者明确他们各自的合作者，及之间要合作的事情，此时选择协作图比较合适。,关于如何选择视图的建议,活动图应该作为描述业务用例场景的必选方式。时序图和协作图作为辅助。
26、在分析业务的阶段，最重要的内容是得到业务参与者的职责，此时离编程还比较远，一般不需要过于强调时序和交互这些对较低抽象层次对象比较重要的内容。,业务用例规约,视图虽然形象、直观，但一些细节性的内容还是需要用文字来说明。例如一些重要的前置、后置条件。示例：书本P236,业务对象模型,对于业务用例规约中列出的业务实体，实际来自业务对象模型的建模结果。,业务用例实现视图,业务用例实现表示一个业务用例的一个或多个实现方式。,问题：,当同一个业务目标有着多种可能的实现方式时，就可能出现多个业务用例实现，每个用例实现描述一种实现方式；如果只有一种实现方式，是不是就不需要特别强调业务用例实现了呢？业务用例实现
27、是否为必须？为了节约工作量，可以考虑为了文档统一，也可以不省略。,业务用例实现场景,针对业务用例场景中的单个活动进行建模，着重描述如何通过人机交互来完成业务。与客户就如何操作达成共识。是制作系统原型的依据。,业务用例实现场景申请登记实现,问题：,如果采用了业务用例实现，是不是必须为业务用例实现绘制实现场景呢？不一定，视实现的复杂程度定。,包图,业务建模过程中，包图用于信息分类。更多的采用领域包的版型。依据实际情况，项目可能会采用不同的分类标准。,业务模块领域包,领域建模,复杂的事物总是由一些简单的物质通过一定的关系组合起来的。领域建模就是要发现表象之下的本源，找出那些最基本的对象以及它们之间的
28、关系，并描绘出这些对象如何交互形成了我们分析的问题领域。,建立领域模型,领域：分析问题时将整体分解以后的相对独立部分。领域分解：针对一个整体提出许多关心的问题，再针对每个问题求解。这些问题不会覆盖所有的业务范围，相互之间也没有什么因果关系。,选择领域范围,不需要把问题完全分解成领域，也不需要为每个领域都建模；只要挑选对业务来说重要的、对过程来说核心的，或对系统来说复杂和困难的部分来建模。例如：银行储蓄业务开发系统海量数据处理领域银行代收业务第三方接口领域,建立领域模型的步骤,提出领域问题分析领域问题建立领域模型检验领域模型,提出领域问题,用户档案与用电企业的各个部门都有关系，而这些业务部门关心
29、的和处理的数据又各有不同，因此有必要建立一个用户档案模型，描述清楚用户档案的构成，以及档案个部分与各业务部门之间的存取关系。提出领域问题：如何建立和管理用户档案。,提出领域问题,案例学习中，要边学习边思考：为什么需要领域模型？如何建立领域模型？,建立和管理用户档案问题领域基本情况,建立和管理用户档案问题领域基本情况,业务服务部门，问题一建立基本用户档案，包括客户资料、用电情况基本资料等。如客户要改变档案，必须通过业务服务部门办理相关变更业务。,建立和管理用户档案问题领域基本情况,用电检查部门，问题二依据用户的电气资料、用电情况基本资料安排检查计划，并记录检查结果。检查过程中发现的问题、处理结果
30、等都归入用户档案。用户若违章用电、窃电，处理结果将影响用电业务的办理，如问题不解决，不得增加电容量。,建立和管理用户档案问题领域基本情况,资产管理部门，问题三：依据用户档案和用电情况为其配备计量资产，制定资产管理计划和轮换计划。用户使用过程中发现的资产维修、校调、丢失等情况将计入用户档案。资产计量不准确引起的计费误差将反映到电费管理部门予以修正。,建立和管理用户档案问题领域基本情况,电费管理部门，问题四：依据用户档案中的用电情况和电气资料情况核定电价。每月依据电表抄表部门所抄录的电表示数计算电费。对一些特殊费用核准后进行差额计算。电费计算记录和收费记录都进入用户档案，以备查询。,建立和管理用户
31、档案问题领域基本情况,电表抄表部门，问题五：电表抄表部门将根据用户档案中的用户地址、电表所搭接的变压器位置等信息编排抄表计划。抄表过程中发生的一切异常均要反映到用户档案中，由用电检查部门负责调查。,建立和管理用户档案问题领域基本情况,现场施工部门，问题六：依据用户基本资料确定如何为客户安装用电设备，安装结果将形成电气资料，归入用户档案。作为用电检查、电价核定以及将来维修等的依据。,建立和管理用户档案问题领域基本情况,财务管理部门，问题七：依据用户的电费和欠费情况统计各类营业报表。欠费记录还将记入用户档案。欠费由业务部门负责追缴，未清欠之前业务部门不再为该用户办理其他业务。,提出该问题领域的原因
32、,从上述描述中，可以知道用户档案的复杂程度和其对项目成败的重要程度。若不在早期将用户档案问题搞清楚，留到编程时考虑就会产生极大的困难，也会面临极大的风险。因此要对用户档案建立领域模型。,分析领域问题,可以将领域建模过程看做一个提出问题和求解的过程，领域模型要做的事情就是：为问题领域寻找和建立起适合的业务对象，这些业务对象以及相互之间的交互来满足问题领域的要求。,类比解方程,设定未知数、列出方程、求解。未知数 要寻找的领域对象方程 对象的交互场景解 领域对象模型,用户档案领域模型,未知数要寻找的领域对象-用户档案模型的领域对象方程对象的交互场景-业务用例场景解领域对象模型-用户档案模型,分析示例
33、：问题一,业务服务部门将建立和变更用户档案中的哪些部分？哪些业务流程将改变用户档案中的哪些部分？要从业务服务部门的业务用例场景中去寻找，因此建议建立业务用例模型后再来推导领域模型。,回顾低压用电申请业务用例场景时序图,建立用户档案方程一,申请单、现场勘测单、现场安装工作单、电表表底等业务对象构成了建立用户档案的基本依据。再次遍历所有业务服务部门的业务用例场景，寻找到所有与建立、修改用户档案相关的那些业务过程和业务对象，即可得到建立与修改用户档案的方程。,申请永久用电业务对象图,其含义是：经过业务用例场景后，申请单、现场勘查单、现场施工单、电表安装单这些业务对象构成了用户档案。例如：针对申请单这
34、个输入，可以假设说这些输入的结果形成了用户档案的一部分，在用户档案中应当对应的为其建立一个领域对象，可以取名为“基本情况”。,逐步分析后面六个问题,得到以下几个用户档案的组成部分，称为待解决问题领域当中的变量。,建立领域模型,上述问题领域变量就是领域模型的基本构成。但这些变量未必是最终结果，后续分析中，也有可能增加、减少、合并、拆分这些变量形成最终的结果。把上述变量结合领域问题中的要求，把它们绘制出来，得到用户档案领域模型,用户档案领域模型,至此，用户档案的基本结构已经形成，不过这些领域对象现在还比较粗略，每个领域对象实际上对应的是一组业务对象。如果仅仅想获知用户档案的构成，到这里就可以结束，
35、详细构成可以在后面的系统分析阶段在来明确。如果希望在此时了解用户档案的更多信息，可以继续进行分析。,了解用户档案的更多信息,遍历用电检查部门、资产管理部门、电费管理部门等所有相关业务用例场景，了解这些部门的业务将如何影响、影响上述哪些基本对象的哪些数据，得到每个领域对象在不同的场景中受到的影响。综合考虑这些影响，构思出一个可行的解决方案，决定出合适的业务对象和业务对象结构，领域对象模型。,例如：“基本资料”领域对象分析,从所有对基本资料有影响的业务用例场景入手，查看有些什么业务对象与基本资料有关，这些业务对象又是如何构成的。,基本资料：来源于申请单，通过对申请单的分析，得到其构成：用户信息、申
36、请资料等。,验证领域模型,为了验证我们得到的领域模型是不是正确的，可以将得到的领域对象带入各个业务用例模型中，看它们是否能满足业务要求。,例如：将领域对象带入抄表部门编排抄表计划业务用例场景,归纳领域建模过程和方法,要能提出问题。通常问题来源于业务核心、重点、难点，也可能来源于客户的特殊要求。弄清楚并描述出面临的问题是什么。分析每个问题，提出假设，将假设中的领域对象视为未知数进行求解。,归纳领域建模过程和方法,找出与之前已经建立的与该问题领域有关的那些业务用例场景，从中找出业务用例场景对未知数的影响。遍历相关业务用例场景，对未知数进行调整，使之尽量能够满足所有的业务用例场景。绘制出领域模型的静
37、态图，绘制出领域对象，领域对象之间的关系以及领域对象与业务对象之间的关系。选取一些重要的业务用例场景验证领域对象。,进一步讨论之一：为什么需要领域模型？,用例分析方法是有缺陷的：它可以很好的说明一个系统的功能性需求，从什么人做什么事的角度来定义系统，但是用例分析方法忽略了一些关联性的问题，用例是独立的，而有些问题是跨越多个用例的。例如：电力营销系统中的用户档案的存取。单个用例的用例场景无法完整说明某些复杂对象的变化，此时领域模型就是一种很好的手段。,进一步讨论之一：为什么需要领域模型？,用例分析方法只能分析功能性需求，对于非功能性需求和计算密集型需求显得很为难。例如：界面个性化、单机游戏等场合
38、。如果使用领域模型则：界面个性化-Portal解决方案单机游戏-控制领域、音效领域、3D引擎领域等,进一步讨论之二：怎样选择问题领域？,一些基本原则：简单需求无需建立领域模型只需要针对核心业务建立领域模型针对系统难点建立关注非功能性需求,进一步讨论之三：领域模型要做到什么程度？,一般情况下，领域模型包含静态图、和动态图但不是每个领域模型都要做到如此详细的地步，可以根据要求进行一些取舍。领域模型还是属于高层次的抽象，框架意义大于实现意义。,提炼业务规则,业务规则用于说明人们希望这个系统怎么做。很容易发生变化。其重要性不亚于业务需求。,业务规则的类型,全局规则交互规则内禀规则,全局规则,指对于系统
39、大部分业务或系统设计都起约束作用的那些规则。一般用于限制功能性需求的，与所有用例都相关。例如：参与者要操作用例必须获得相应的授权。建议将全局规则写入软件架构文档，并对其变更进行管理。,交互规则,产生于用例场景中，体现为业务流程的流转规则。例如在活动转移、状态变迁和对象交互时必然会有一些限制性的条件，就是交互规则。特殊的规则：UML入口条件、前置条件UML出口条件、后置条件其变更管理可视为业务用例变更，一并纳入业务用例变更管理。,内禀规则,指业务对象本身具备的，并且不因为外部的交互而变化的规则。是业务对象的内在规则，应写入业务对象描述文档中。,分类业务规则的意义,全局规则：是系统应该具备的特性，
40、其变化通常引起架构或者框架的变更，因此 最好将其单独提取出来管理交互规则：需求变更大部分源于此单独列出并考虑采用设计模式来保证扩展性内禀规则：与外部交互无关，应该封装到对象中。,业务规则管理,可以采用与需求管理一样的管理模式和过程，清晰的体现各种类型的业务规则及其变更过程。这将有助于提高各类开发人员的工作效率。,获取非功能性需求,在最基本的层次上，客户需要所开发的软件能满足他们日常工作的需要。但客户通常不满足于基本的物质需要，而存在更多非物质需要，例如：操作简便、界面美观、个性化,如何获取非功能性需求？,比较简单：非功能性需求总是比较固定的几个范围。比较复杂：随着软件规模的不断扩大和应用环境的
41、日趋复杂，确定非功能性需求指标需要考虑越来越多的因素。,非功能性需求,可靠性：安全性现已越来越趋向由第三方工具支持，很多时候不再需要软件本身去实现复杂的安全机制事务性与应用环境密切相关，小型系统中一般通过数据库本身的事务出来机制来保障；大型项目一般会购买专门提高事务处理机制的服务器，不需要自行编程实现。,非功能性需求,稳定性：有故障频率、严重性、可恢复性、可预见性、准确性和平均故障间隔时间等指标构成。可用性容易学习、使用效率、记忆性错误恢复、主观满意度、人员因素、美观用户界面一致性、联机帮助和环境相关帮助向导、代理、用户手册、培训材料,非功能性需求,有效性：性能：速度、并发性、吞吐量、响应时间、资源占用率可伸缩性：向系统增加资源时性能的改善可扩展性：系统级、软件架构基本的扩展可移植性,如何采集非功能性需求？,通常需要需求人员主动引导。需求人员在需求过程中需要了解系统的应用环境，这是确定非功能性需求的重要依据：硬件环境、网络环境、用户情况、预期使用人数、并发使用情况等示例：见书本P267,
