??xml version="1.0" encoding="utf-8" standalone="yes"?> 企业领域中Q何一必遵守的条gQ?/span>ConditionsQ、约束(ConstraintsQ或政策Q?/span>PoliciesQ都是业务规则?/span> 可以业务规则分Z大类Q分别ؓQ约束规则(Constraint RulesQ与衍生规则Q?/span>Derivation RulesQ?/span> U束规则主要用来U束对象l构和行为;衍生规则主要是推论约束和计算公式。细分类如下Q?/span> 1Q?nbsp;U束规则Q?/span>Constraint RulesQ?/span> aQ?nbsp;刺激/反应规则Q?/span>Stimulus/ Response RulesQ?/span> bQ?nbsp;操作规则Q?/span>Operation Constraint RulesQ?/span> cQ?nbsp;l构规则Q?/span>Structure Constraint RulesQ?/span> 2Q?nbsp;衍生规则Q?/span>Derivation RulesQ?/span> aQ?nbsp;推论规则Q?/span>Inference RulesQ?/span> bQ?nbsp;计算规则Q?/span>Computation RulesQ?/span> 刺激/反应规则 当(WHENQ某个重要的外界事g发生Q而且Q?/span>andQ对象如果(IFQ恰好处于某U状态下ӞQ?/span>THENQ对象就会做出某U事先约定好的行为。简a之,WHEN and IF条g成立Ӟ对象׃?/span>THEN的反应?/span> 操作规则 操作规则Q?/span>Operation Constraint RulesQ用来保证操作会正确执行Q通常又分?#8220;操作前规?#8221;Q?/span>Operation Precondition RulesQ及“操作后规?#8221;Q?/span>Operation Postcondition RulesQ?/span> 只要Q?/span>ONLY IFQ?#8230;…且(andQ?#8230;…执行Q?/span>ExecuteQ?/span> l构规则 l构规则Q?/span>Structure Constaints RulesQ用来约束对象种cL兌关系必须永远遵守规则。在cd里,最Ҏ表达l构规则?/span> 推论规则 推论规则Q?/span>Inference RulesQ指出某事实Q?/span>FactsQؓ真(TrueQ时Q结论(ConclusionQ可被推论得出?/span> IF …… THEN …… 计算规则 计算规则Q?/span>Computation RulesQ就是一般所谓的计算公式?/span> 业务规则散落四处Q系l分析员可以通过不同的的UML图,重新l织且呈C务规则,如下Q?/span> aQ?nbsp;PIM-1的系l用例叙qͼ以系l流Eؓ主,记录U束程的业务规则?/span> bQ?nbsp;PIM-2的状态图Q以对象行ؓZQ记录刺Ȁ对象反应的业务规则?/span> cQ?nbsp;PIM-3的类图,以静态结构ؓ主,记录U束对象U类或关联关pȝ业务规则?/span> 在进?/span>PIM-1Ӟpȝ分析员已l广泛地C一些重要的业务规则了。接着Q系l分析员可以从中扑և涉及多项业务规则的业务对象(Business ObjectQ,q于此处?/span>PIM-2Q再q一步通过状态图Q组l且记录更多重要的业务规则?/span> 同时Q系l分析员l过了徏立状态图的思考过E之后,可以寚w要业务对象的状态变化更加清楚。系l分析员可以用一张状态图呈现某一U重要对象一生的行ؓ。从对象诞生到灭亡期_它会对哪些事ӞEventQ有所反应Q因而{换(TransitionQ其内在状态(StateQ,和执行某些特定的动作Q?/span>ActionQ?/span> 针对对象一生中可能执行的一l动作,pȝ分析员用状态来分组q些动作。因此,对象一旦{换进入某一个状态之后,其可执行的动作就会被U束Q直到发生了重要事g之后Q对象才会{换到另一个状态,同时也执行新状态内部规定好的动作?/span> PIM-1~PIM-4?/span>UML产生l果Q将作ؓ需求文件中的一部分Q而其余非UML产生的结果,pȝ分析员视目规定或以往l验自行产生?/span> ?/span>PIM阶段中,pȝ分析员负责生?/span>PIM-1~PIM-4Q至于其余的PIM?/span>PSMQ则由其他开发h员负责生成?/span> PIM-1~PIM-4的生结果如下: PIM-1Q分析系l流E(pȝ用例叙述Q?/span> PIM-2Q分析业务规则(状态图Q?/span> PIM-3Q定义静态结构(cdQ?/span> PIM-4Q定义操作及ҎQ序列图Q?/span> 在进?/span>PIM阶段之后Q系l分析员所有系l用例依相关性分成若q组Q以l别方式生成该组pȝ用例涉及?/span>PIM-1~PIM-4产生的结果,随后交给后箋的开发h员进行设计,~码及测试。然后逐步生成一l一l的PIM-1~PIM-4产生l果Q跟CIM的生成方式不同?/span> pȝ分析员逐步生成PIM的可能情况: W一阶段Q进?/span>CIM-1Q生成业务用?/span> W二阶段Q进?/span>CIM-2Q生成活动图 W三阶段Q进?/span>CIM-3Q生成系l用?/span> W四阶段Q决{h员从CIM-3挑选出一些系l用例,作ؓ首期pȝ范围。接着Q系l分析员挑选出来的pȝ用例Q以光域知识的相关性分l?/span> W五阶段Q生成第一l系l用例相关的PIM-1~PIM-4分析文gQƈ交由后箋的开发h员进行设计、编码及试?/span> W六阶段Q依ơ生成其它组的系l用例相关的PIM-1~PIM-4分析文gQƈ交由后箋的开发h员进行设计、编码及试?/span> PIM-1Q系l用例叙q?/span> 针对每一个系l用例,pȝ分析员分析其内部l节Qƈ~写成系l用例叙qͼUC DescriptionQ?/span> 一份用例叙q格式里头包含多字D,pȝ分析员可以从中挑选适用的字D늻成自q用例叙述格式?/span> 1?nbsp;用例基本数据 ?/span>用例名称 ?/span>用例~号 ?/span>用例q?/span> ?/span>用例?/span> ?/span>pȝ ?/span>执行?/span> ?/span>相关用例 2?nbsp;执行程 ?/span>主要程Q?/span>Basic FlowQ?/span> ?/span> 替代程Q?/span>Alternate FlowsQ?/span> ?/span> 例外程Q?/span>Exception FlowsQ?/span> 3?nbsp;条g及规?/span> ?/span>启动事g或条ӞTriggersQ?/span> ?/span>前置条gQ?/span>PreconditionsQ?/span> ?/span>后置条gQ?/span>Post conditions on SuccessQ?/span> ?/span>p|时状态(Status on FailureQ?/span> ?/span>业务规则Q?/span>Business RuleQ?/span> 4?nbsp;相关文档 ?/span> 用例叙述的历史版?/span> ?/span>UML?/span> ?/span>参考画?/span> ?/span>其他?/span>UML文档 5?nbsp;其他事项 ?/span>优先性(PriorityQ?/span> ?/span>q代{Q?/span>IterationQ?/span> ?/span>待解决问题(IssuesQ?/span> ?/span> 基本假设Q?/span>AssumptionsQ?/span> ?/span>相关人员 ?/span>Ҏ需求(Special RequirementsQ?/span> 相关用例Q常见的相关性有两方面,其一是执行用例前必须先行执行q某相关用例Q其二是执行用例期间可能驱动其他的包含用例(Inclusion Use CaseQ,或是因条件符合驱动其他的扩展用例Q?/span>Extension Use CaseQ?/span> ql内部而言Q各用例在其q后都是׃n同一对象。也是_UC之间自然具?#8220;׃n对象”之关pR但是,׃用例囑֏呈现pȝ外观Q所以在用例N看不到这U关pR在外观斚wQ?/span>UC之间有两U关p,分别?#8220;包含”Q?/span>IncludeQ和“扩展”Q?/span>ExtendQ关pR?/span> 两个用例之间可以?#8220;包含”关系Q用以表C某一个用例的对话程中,包含着另一个用例的对话程。一旦出现数个用例都有部分相同的对话程Ӟ相同的程记录在另一个用户中Q前者称?#8220;基用?#8221;Q?/span>Base UCQ,后者称?#8220;包含用例”Q?/span>Inclusion UCQ?/span> 如此一来,q些基用例就可以׃n包含用例了?/span> a之,包含关系是来自于抽象Q?/span>AbstractionQ,即从C不同的用例之中,抽离出共同的部分Q而成为可以重用的用例?/span> 两个用例之间q可以有“扩展”关系Q用以表C某一个用例的对话程Q可能会依条件时插入另一个用例的对话程中。前者称?#8220;扩展用例”Q?/span>Extension UCQ,后者称?#8220;基用?#8221;Q?/span>Base UCQ?/span> a之,扩展关系来自于用例内执行zd的过E分Z要过E(Main CourseQ及可选择性过E(Alternative CourseQ?/span> 执行程 主要程Q这是用例叙q最核心的部分,其记载了整个用例正常的执行过E?/span> 替代程Q一个用例叙q里面,通常会包含一D主要流E,同时可以包含数段替代程?/span> 例外程Q用例执行失败的情况?/span> 用例成功执行的过E中Q正常流E就是主要流E,期间出现的小插曲是替代程。但是,例外程处理的是Q用例执行失败的情况?/span> 条g及规?/span> 启动事g或条Ӟ记录启动用例的重要事件或条g?/span> 前置条gQ这是执行用例之前的验,唯有在满x些重要条件时Q才会执行该用例Q以保用例可以正确执行?/span> 后置条gQ相对于前置条gQ后|条件代表用例执行完毕时Q可以通过后置条g自行验是否执行成功?/span> p|时状态:记录用例执行p|时的状态?/span> 业务规则Q重要的业务规则或计公式都要记录下来?/span> 业务人员在执行业务流E时Q会使用到许多重要的业务规则或计公式,q些也都是系l必遵守的条g及规则,所以必记录下来?/span> 相关文档 ׃用例驱动Q?/span>Use Case DrivenQ是当今软g开发的基础模型Q所以用例叙q常作ؓpȝ开发文件的汇集点,同它链接到相关的文档?/span> 用例叙述的历史版本:用例改版Ӟ用例叙述也跟着同步改版。用例叙q是参与人员的智慧成果,也是业务l织的重要资产。所以如果有需要保留用例叙q的历史版本Ӟ可以在现行版本里多加一个字D,以链接旧有的历史版本及改版说明?/span> UML图:跟该用例相关的业务用例图、活动图、系l用例图、状态图、类图或序列图,{等?/span> 参考画面:有时候附上画面设计的囄Q让阅读者可以对该用例有更具体的惌?/span> 其他?/span>UML文档Q例如会议记录?/span>表设计等?/span> 其他事项 优先性:替用例标C其重要度或优先性,可以协助订定开发用例的序Q越重要的越优先开发?/span> q代{Q替用例标示其细致度或P代等U,方便开发h员经q多ơP代的q程逐步定义出用例的l节?/span> 待解决问题:在用例分析与开发期_可能会出现还没有定论的问题,q时候通过用例叙述把问题记录v来,方便指派负责人员以及日后查阅?/span> 基本假设Q如果该用例是基于某个基本假设而设计出来的Q记下这个重要的基本假设?/span> 相关人员Q每一份用例叙q都涉及几种不同w䆾的相关h员,包括制作者、阅读者和审核者,{等?/span> Ҏ需求:跟该用例相关的非功能性需求等Ҏ需求,都可以记录在q个字段中?/span>
]]>
随后Q项目正式进?/span>PIM阶段Q也是正式进入分析阶D,pȝ分析员将针对首期的系l用例详q细节规|作ؓ正式需求文件的一部分Q也作ؓ业务人员与开发h员之间的沟通文件?/span>
]]>
无法定pȝ范围Q就无法估算pȝ开发所需的成本及旉Q当然整个项目也无法全面展开。所以,pȝ分析员要快完成此项目,最好在一、两周内可以依次生成下列UML文gQ?br> ●CIM-1Q定义业务流E(业务用例图)
●CIM-2Q分析业务流E(zd图)
●CIM-3Q定义系l范_pȝ用例图)
CIM-1Q?br> pȝ分析员经q了CIM1~3阶段之后Q将定义Z堆的pȝ用例Q随后从中挑选出首批开发的pȝ用例Q这才算定了系l范_也才能够估算开发成本及旉Qƈ且正式进入PIM阶段?br>
业务用例囄主要l成元素是业务用例和业务执行者。每一个业务用例代表一条业务流E,业务执行者则代表位于业务l织外但会启动或参与业务程的hQ或其它pȝQ?br>
CIM-2Q?br> 通过CIM-1圈出了系l将参与的业务流E之后,针对每一个业务用例,pȝ分析员得开始分析它的工作流E,q且l制zd图(Activity DiagramQ与业务人员取得p。随后到了CIM-3Ӟ才能够依此定义出pȝ可以协助之处Qƈ且规划出pȝ范围?br>
选用zd图作为分析业务流E的工具Q主要是因ؓ它能够让pȝ分析员聚焦在程内部的一q串工作。在q一q串的工作项目中Q有些工作项目可能是Uh工操作,另一些工作项目则可能有系l的协助。找出可信息化的工作目Qƈ以此定义出系l未来可以提供的服务目Q也定义出初步的系l范围了?br>
CIM-3Q?br> l过了CIM-1的定义业务程序以及CIM-2的分析业务流E之后,l于q入到CIM-3q场压u戏了。CIM-1和CIM-2的生成文Ӟ跟CIM-3的生成文件之_有如下的兌性:
●CIM-1中的业务执行者,以及CIM-2中的动作负责人,都可能成为CIM-3的系l执行者(System ActorQ?br> ●CIM-2zd图中的每一个动作,都可能成为CIM-3的系l用例?br>
在CIM-3中,pȝ分析员将分析CIM-2生成的所有活动图Q定义出一堆的pȝ用例。随后,待项目经理及相关人士从中挑选一批系l用例,作ؓ首期发布QReleaseQ的pȝ用例。此外,pȝ分析员也带着q批选中的系l用例进入PIM-1Q开始详q每一个系l用例的详细规格?br>
pȝ分析员在定义pȝ用例Ӟ可以参考下列徏议:
1、每一个系l用例最好只有一个启动者?br> 2、系l用例执行时_如果有联机其他系l,它们列为支持者?br> 3、遇到定时启动的pȝ用例Q可以定义一个名?#8220;定时启动者(TimerQ?#8221;的虚拟启动者?br>
启动用例的执行者,特称?#8220;启动?#8221;QInitiatorQ,其余不具有启动特质的执行者,可称之ؓ“支持?#8221;QSupportQ。直接操作计机的用P通常是pȝ用例的启动者。而且在系l用例执行期_有时会需要联机其他系l以取得协助Q这些联机系l就是支持者?br>
pȝ分析员可以先?#8220;CIM-1的业务执行?#8221;?#8220;CIM-2的动作负责h”q两处先扑֯Ȁz者?br>
pȝ分析员在l制pȝ用例图时Q可以采用下列几常见做法:
1、采用带头关系U,让启动者指向用例,用例指向支持者。这样一来,从图上就可以明确分L出启动者与支持者?br> 2、一个用例通常只有一个启动者,不过可能出现多个支持者?br> 3、如果有多个启动者的情况Q尝试切割成一Z会话QOne user, One SessionQ?br> 4、有时不同用户都h启动用例的特性,在图上绘出最重要或最主要的启动者,Z启动者记录在用例叙述里,q样可以降低囄复杂度?br>
]]>
MDAQ?/span>Model-Driven ArchitectureQ与UMLQ?/span>Unified Modeling LanguageQ同?/span>OMGQ?/span>Object Management GroupQ机构之标准?/span>
MDA主要生成的UML模型Q分Z列三个阶D:
?/span> CIMQ?/span>Computation Independent ModelQ——聚焦于pȝ环境及需求,但不涉及pȝ内部的结构与动作l节?/span>
?PIMQ?/span>Platform Independent ModelQ——聚焦于pȝ内部l节Q但不涉及实现系l的具体q_Q?/span>PlatformQ?/span>
?PSMQ?/span>Platform Specific ModelQ——聚焦于pȝ落实于特定具体^台的l节。例如,Spring?/span>EJB2?/span>.NET都是一U具体^台?/span>
最后,E序员会依据PSM?/span>UML模型内容Q按图施工,~写出适用于特定具体^台的代码?/span>
MDA提出的解x法——将企业及应用系l与实现技术^台分,且以l一建模语言UML来表达与q_无关?/span>PIMQ然后再设计出适用于特定^台的模型PSM。如此一来,因ؓ分隔且封装了企业与技术两斚w的变化,所以降低了两者之间的牵动?/span>
MDAd设计切分成PIM?/span>PSM?/span>
MDA目开发的W一步骤?/span>CIM开始,不同?/span>PIM?/span>PSMQ?/span>CIM试图表达信息pȝ的应用环境,而非信息pȝ本n?/span>
在进?/span>CIMӞ兛_的是与企业相关的营运目标、实现条件及q作程{,先了解信息系l的应用环境Q才有可能ؓ企业量n打造出完善的信息系l?/span>
在经历构?/span>CIM的过E中Q除了可以逐步了解企业Q同时也建立与业务h员之间的沟通方式及默契Q还让业务h员可以参与信息系l的开发?/span>
CIM旨在记录企业领域里的重要需求与概念?/span>
PIM?/span>PSM之间的界限,比较ҎhQ两者所兛_的主体都是信息系l,分别的界限在?#8220;q_”Q?/span>PlatformQ一词?/span>
a之,PIM?/span>PSM的界限在于,是否支持特定的具体^台。前者与具体q_无关Q后者则得适合某一个特定的具体q_?/span>
分析步骤参考:Q?/span>CIM?/span>PIM阶段Q?/span>
CIM-1Q定义业务流E,产生业务用例模型?/span>
CIM-2Q分析业务流E,产生zd图?/span>
CIM-3Q定义系l范_产生pȝ用例图?/span>
PIM-1Q分析系l流E,产生pȝ用例叙述?/span>
PIM-2Q分析业务规则,产生状态图
PIM-3Q定义静态结构,产生cd?/span>
PIM-4Q定义操作及ҎQ生成序列图?/span>