定pȝ需求即定pȝ用例。方法以Ҏ业务用例实现场景分析入，分析每个pȝActor的系l用例。每个系l用例一定是一个完整的事g，注意业务用例和系l用例的区别Q业务用例是一个完整的业务目标Q而系l用例是一个完整的事g，是业务目标中的一个环节，如客户代表申请开h一个完整的pȝ用例Q但不是一个完整的业务目标Q其包括多个面操作?/p>
3.11 用例实现分析
Ҏ个系l用例，识别其可能的实现路径Q每个实现\径就是一个用例实玎ͼ然后针对每个用例实现Q分析hZ互，使用zd囄制用例实现场景?/p>
3.12 分析模型
使用分析对象Q实现所有的用例实现场景Q识别出三种分析对象。在q个q程中，也可以徏立界面原型，和客戯一步达成需求的一致理解。分析模型是需求到设计的桥梁，分析cȝ层次高于设计实现Q需求通过分析c{成计机语言。后l做pȝ设计的时候，可直接将分析模型转换成设计模型?/p>
在考虑分析模型的过E中Q有可能识别Z些公共模块，比如开戗销戯E中都会有一些业务规则校验，需要引入规则引擎的支持Q那么类D则引擎这L公共模块需要添加到逻辑架构中去?/p>
3.13 非功能性需求设?/strong>
以性能Z讲一下对非功能性需求设计的q程?/p>
1、确定性能目标Q要支持多少用户、多在U用戗多ƈ发操作、操作响应时间要求等Q?/p>
2、以一个简单的三层架构v点，Ҏ性能目标Q识别瓶颈。比如，如果数据库撑不住Q那么需要考虑最佳的分库设计Q如果是逻辑层撑不住Q则要考虑负荷分担Q状态同步的逻辑层方案设计，如果操作响应旉要求很高Q则可根据不同场景，分析其操作的数据的读写特点，采用合适的~存Ҏ。如要支撑高q发低时延的大数据量查询QTwitter采用了垂直~存Qraw~存的设计方案?/p>
3、验证性能设计。抽取典型场景，实现一个prototype来验证性能设计是否满性能目标?/p>
在质量属性设计中Q如果需要新增模块，则需要修攚w辑架构?/p>
有一些约束类需求也是非帔R要的Q不能遗漏分析?/p>
l过q一个阶D，我们能够得到一个比较完整的逻辑架构Q运行架构、开发架构、物理架构、数据架构的输入了。剩下的工作是~档的工作了?/p>
3.14 架构~档
有了上面的工作作为铺垫，~档非常容易了Q这个就不细讲了?/p>
分别针对上节中业务用例视图中的每一个用例，分析该业务用例在实际工作中是如何做的Q一般用业务活动图来表qC务场景。在q个阶段Q有几点需要特别注意的地方Q?/p>
1、关注参与业务用例的各个参与者是如何协同的，如一个简化的用户开L程是填写营业员提交开戯?》主审批订?》施工h员行订单；
2、对一个业务用例，如果有不同的实现路径Q需要做不同的场景分析。例如，用户订购产品Q分|上订购和营业厅订购q两U场景，两个场景大不相同Q?/p>
3、场景的步骤_度Q用L一个完整操作目的，如用户开P则用户填写订单是一个步骤，而不用细化到用户取单、拿W填单等Q?/p>
3.5 产生业务对象模型
针对每个业务用例Q根据业务用例场景，分析该用例中涉及的业务实体，q绘制业务对象模型图?/p>
3.6 产生业务用例实现视图
业务用例实现指业务用例的一U实现\径，一个业务用例实现对应着一个业务用例场景。业务用例实现视图是表述业务用例实现的视图?/p>
3.7 分析业务用例实现场景
业务用例实现场景着重描q如何通过人机交互来完成业务，是业务用例场景的具体化。一般用zd图来表述人机交互程。这里每个步骤的_度是h与系l或pȝ与h的一ơ交互?/p>
3.8 领域建模
领域模型是描q特定问题域的对象及其相互关pR领域模型对业务对象做了q一步的_。领域徏模的步骤如下Q?/p>
1、确定问题域Q如CRM中的客户模型比较关键Q我们决定对其进行领域徏模，则需要将设计客户业务实体的用例全部识别出来；
2、领域徏模：逐一分析涉及到操作客h型的业务用例场景Q识别领域对象以及对象之间的关系Q?/p>
3、验证领域模型：使用序列图作为工PZ领域模型来编排实现各业务场景Q如果能实现Q证明领域模型ok?/p>
领域对象跟业务对象有区别Q我认ؓQ业务对象不是领域对象。业务对象来自于业务用例Q是业务中客观存在的Q而领域对象是对业务对象做q一步抽象、精化后的结果，是h对业务的主观认识Q这是Z么不同厂商的产品模型会不一L原因Q而且q不是所有的领域对象都是Ҏ业务对象分析而来的。比如，某CRM产品面向全球市场Q可定制能力是关键，为提升可定制性，需要构Z个快速开发框Ӟq个快速开发框架也是Y件系l的一部分Q也是有领域模型的，但是它的领域模型跟业务对象没半点关系?/p>
3.9 产生逻辑架构草稿
通过上述步骤Q我们已l有了部分领域模型，针对每一个可直接映射C务对象一U的领域对象Q可规划相应的业务模块，如有开戯单，那么可以有订单管理，有客L理等。业务模块的划分_度可依据大概的工作量而定Q保证最低别的业务模块的工作量是大致均匀的。这仅仅是一个徏议，可以Ҏ目的实际情况决定?/p>
Z上述的成果，我们q只能Z个逻辑架构的草E，因ؓ我们q没有分析质量属性，后箋对质量属性做设计的时候，q有可能会引入新的模块。比如要让业务流E可快速编排、定Ӟ我们希望引入工作，那么逻辑架构中也要引入一个工作流模块?/p>
待箋。。?/p>
本hl历q不项目，一些项目的架构设计负责力很强，接到zM后，马上一头扎q设计，抽象Z堆玄玄乎乎的概念Q讲得h晕头转向的，让h觉得高深莫测Q但是，在会议上却被涉众提的一些简单的问题问得很仓促，I其ҎQ还是漏考虑了涉众的需求，被h提问而又~Z准备Q是不是很多人有cM的经验？Q）
我们q经帔R到的场景是设计h员通常Z些模型、概念争Z休，公说公的׃Q婆说婆的漂亮，其实模型概念q东西就像h的h生观和世界观Q是人对世界和h生的主观认识Q可能随着q龄阶段的变化而变化，而且有时候没有绝对的对与错，像有些人喜Ƣ金戈铁马，有些人喜Ƣ与世无争，我们很难说谁一定是对的一定是错的Q遇到这U清醒时Q我停下争论Q争论方各自拿出实际的业务场景来验模型，哪个模型对场景的满度更好，实现成本更低则更好，如果两个都挑不出刺儿Q随侉K一个即可?/p>
q有一些架构设计h员喜Ƣ创造一些与众不同的概念Q让人看上去昑־高深莫测。我觉得如果一个架构师能够用最的语言、文字把问题和方案讲清楚Q那才是真正的有水^Q你让h晕头转向的时间既是项目的成本Q因此，我们创造概念词汇的时候，需要从涉众的角度出发，我这里的意思不是盲从涉众语a词汇Q而是说出发点从涉众角度出发，如果涉众原本使用的语a不够准确Q我们可以跟他们一h讨，定义更合适的概念词汇?/p>
q有一个就是对软g竞争力的认识。有人通过包装一堆玄玄乎乎的概念来显得很高深莫测Q试N过q种方式让h觉得有竞争力Q我认ؓQ竞争力首先是要跟对手比Q其ơ一定是涉众能感知的Q能够涉众带来正向h值的Q比如省多少成本Q端到端业务程节约多少旉?/p>
我认为遵循一个科学的架构设计q程跟上提到的软g架构4+1视图法是架构设计的两个法宝，一个指导思维、定义输出，另一个指导如何来做，相辅相成Q确保架构设计h员全面而正的理解需求，做好需求^衡、设计^衡，设计出实用的、能落地的架构?/p>
下面我会按顺序讲解架构设计的q程Q以及每个步骤具体要做的事情?/p>
3.1 定涉众
一般来Ԍ涉众包括客户Q资方）、承接方Q劳方）、用戗我们通常扑ֈ代表某一cd的涉众群体的代表人：客户代表、劳方代表、用户代表等。访谈的时候直接找代表q行?/p>
3.2 定pȝ边界
对于要明实现某U标准的软gpȝQ通常定边界非常ҎQ直接按标准圈定的scope分析卛_Q比如像SIPServlet容器Q是要求遵从JSR168规范的，那么软gpȝ的Scope是JSR168规定的ScopeQ但是也有例外，比如客户或者劳Ҏ指定要复用一个现有的实现了部分功能的pȝ或组Ӟ那么Scope׃同了。对于没有标准的软gpȝQ就需要分别访谈客户代表、承接方代表定pȝ边界。ؓ什么要访谈承接方代表呢Q因为承接方代表往往是劳斚w|领导肩负企业战略达成的命，很有可能对系l提出比客户更多的要求。D个例子，某客户需要一个SIP通信协议栈，以实C斚w话的业务，但是x领导认ؓQ后lICT融合是趋势，我们构徏的系l要支持ICT融合应用部v和运行，支持业务标准JSR168规范?/p>
3.3 软g需求收?/strong>
软g需求可分ؓ二类Q?/p>
功能需求（即业务用例）Q描qActorQ用hpȝQ可Z软gpȝ做什么事Q要W合什么业务规则；
非功能性需求又可分Zc：
质量属性：质量属性指软gpȝ的品质，可分行期质量属性与开发期质量属性?/p>
q行期质量属性包?/p>
Q?Q性能Q性能是指软gpȝ及时提供相应服务的能力。具体而言Q性能包括速度、吞吐量和持l高速性这三方面的要求?br> Q?Q安全性：指Y件系l同时兼合法用户提供服务Q又L非授权用功能的能力?br> Q?Q易用性：指Y件系l易于用的E度?br> Q?Q可用性：可用性与易用性不相同。可用性指pȝ长时间无故障q行的能力?br> Q?Q可伸羃性：指当用户增加Ӟ软gpȝl持高服务质量的能力?br> Q?Q互操作性：指本软gpȝ与其他系l交换数据和怺调用服务的难易程度?br> Q?Q可靠性：软gpȝ在一定时间内无故障运行的能力?br> Q?Q健壮性：也称定w性。是指Y件系l在异常情况仍能够正常运行的能力?/p>
开发期质量属性包括：
Q?Q易理解性：是指pȝ设计能被开发h员理解的难易E度?br> Q?Q可扩展性：为适应新需求或者需求变化，Y件增加功能的能力。有些时候，UC为灵zL?br> Q?Q可重用性：重用软gpȝ或其中一部分的能力的难易E度?br> Q?Q可试性：对Y件测试以证明其满需求规U的难易E度。在实际的项目中Q主要指q行单元试{难易程度?br> Q?Q可l护性：修改BugQ增加功能，提高质量属性?br> Q?Q可UL性：Y件系l从一个运行环境{Ud另一个不同的q行环境的难易程度?/p>
U束Q规定开发Y件系l时必须遵@的限制条Ӟ如要Z什么操作系l，要基于什么开发语a{等?/p>
对于功能需求，可找pȝ的直接用用户代表，对其q行访谈Q收集其要基于系l做的事情，可按照标准的用例模板Q在访谈的过E中引导用户代表。之后，l制业务用例视图Qƈ针对每个业务用例Q用标准的用例模板功能需求编档，通常叫用例规U?/p>
对于非功能性需求，可找软gpȝ的涉众，依据下面的模板，引导涉众Q收集其对相应质量属性的要求Q?/p>
ȝQ本阶段需要输Z务用例视图，业务用例规约Q非功能性需求?/strong>
待箋。。?/strong>
]]>
本篇开始之前先扯点闲话Q商业应用系l开发经历了三个阶段Q?br /> W一个阶D以计算Z心，分析设计围绕E序的运行效率，法优劣Q存贮优化来q行?0q代的大学课E讲的都是这些?br />
W二阶段以数据ؓ中心Q分析设计围l数据流q行Q以数据程来模拟业务流E。这也就是所谓的面向q程的分析模式?br />
W三阶段以hZ心，分析设计围绕人的业务需求，使用要求Q感受要求进行。这也就是现在的面象对象分析模式?br />
使用OOҎ建立商业模型必须先定义涉众。商业系l无论多复杂Q无Z么行业，其本质无非是人，事，物，规则。h是一切的中心Qh做事Q做事生物Q规则限制h事物。h驱动pȝQ事体现q程Q物记录l果Q规则则是控制。无论OO也好QUML也好Q复杂的表面下其实只是一个简单的规则Q系l分析员弄明白有什么hQ什么h做什么事Q什么事产生什么物Q中间有什么规则，再把人，事，物之间的关系定义出来Q商业徏模也基本完成了。这时候可以说Q系l分析员已经完全了解了用户需求，可以q入pȝ建模阶段了?br />
书归正传Q上笔者归U了一些典型的涉众cd及他们的普遍期望。接下来Q就是要他们这些期望定义出来。这个过E，是业务用例获取的过E。笔者可以跟大家分n的经验是通过以下步骤q行Q这些步骤ƈ非唯一正确Q对于经验不多的pȝ分析员来_q些步骤很有指导意义?br />
W者做了一个徏模实例，有需要有读者请到笔者的BLOG资源中心下蝲Q实例以上一所q网上图书馆需求ؓ蓝本建立了业务用例模型，之后的概忉|型、系l模型则抽取了其中的借阅q程作ؓ例子。不记得了可以后头找找?br />
建模W一步，从涉众中扑և用户。ƈ定义q些用户之间的关pR在ROSE中，应该使用business actor cd。参考上一的需求描qͼ下蝲实例
W二步，扑և每个用户要做的事Q即业务用例Q在ROSE中应使用Business use casecd。请参考《用例的cd与粒度》一文以帮助定用例的粒度。笔者强烈徏议ؓ每一个business actorl制一个业务用例图Q这能很好的体现以hZ心的分析模式Qƈ且不Ҏ漏掉business actor需要做的事。至于以参与者ؓ中心的视囑֮易漏掉某个业务用例的参与者的担心Q可以在W四步中得到消除。下载实?br />
W三步，利用业务场景囑ָ助分析业务流E，在ROSE中，q个阶段最好用活动图Activity diagram。在q个阶段Q业务场景图非常重要Q在l制q程中，pȝ分析员必采用第一步中定义的用户名字作为泳道名Q用第二步中定义的业务用例名作为活动名来绘制。必这么做的原因是Q如果你无法把利用已l定义出来的 business actor ?business use case完备的描l业务流E，那么一定是前面的定义出问题了，你需要回头审视是?business actor ?business use case定义不完善或错误。如果不是所有的business actor ?business use case 都被用到Q要么应该检查业务流E调研时漏了什么，要么应该查是否定义了一些无用的business actor ?business use case 。同Ӟl制业务场景图也非常有助于选择合适的用例_度q保持所有的用例都是同一_度。下载实?br />
W四步，l制用例场景图。与业务场景图不同的是，用例场景囑֏针对一个用例绘制该用例的执行过E。笔者仍然强烈推荐用activity diagram。在用例场景囄l制中，必须使用W一步中定义的业务用户作为泳道。必这么做的原因是Q它能帮助你发现在定义业务用例图时的错误Q比如是否漏掉了某个业务用例的潜在用者。不是每个业务用例都需要绘制场景图Q只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍焉要在业务用例规约文档中写明。下载实?br />
W五步，从第三步或第四步中绘制的zd图中扑ֈ每一步活动将使用到的或生的l果。这是找到物的过E。找到后Q应当徏立这些物之间的关pR在ROSE中，q称Z务实体模型。应该用business entity cd。下载实?br />
W六步，在上q过E中Q随时补充词汇表Glossary。将此过E中的所有业务词汇，专业词汇{一切在建模q程中用到的需要解释的名词。这份文档将成ؓ模型建立Z读者就模型达成一致理解的重要保证?br />
W七步，Ҏ上一中提到的业主，老板{涉众的期望审视建立好的模型Q确定业务范_军_哪些业务用例在系l徏设范围内。那些不打算U_范围内的业务用例有两U情况，一U是该业务用例是被调用一方，那么应该把它改ؓ boundary cdQ意味着来它是一个外部接口。另一U是该业务用例主动调用系l内业务用例Q那么应该将它改为business actorcd。与普通business actor不同的是Q由业务用例转换而成的business actor不是人，而通常是一个外部系l进E，因此应该在被调用的系l内业务用例与它之间增加一个boundary元素Q意味着我们的系l将样一个外部进E提供一个接口。严格来_那些需要纳入徏设范围的business use case 应当对应的生成一?business use case realizationQ?以后的设计工作将归纳到这些实现用例中。但W者觉得这一步ƈ非很关键的，实际中本Zl常省略q一步，而将协作图，象活动图Q类交互囄直接在business usecase下说明。不q本实例中笔者还是按照正规方法来建模的。下载实?br />
需要说明的是，上述的步骤ƈ非一ơ性完成的Q在每一个步骤中都可能导致对以前步骤的调整。即使徏模已l完成，当遇到变化或发现新问题时Q上q步骤应当从头到ֆ执行一ơ。这也是RUP倡导的P代开发模式?br />
l过以上的步骤，我们已经建立了一个完整的业务模型。但q决不是建模工作的全部，以上q程只说明了建立一个完整业务模型的q程Q不能说q样徏立了一个很好的业务模型。因Zq的q程中ƈ没有提及业务分析q程。分析过E全凭系l分析员的经验，对OO的理解和对行业业务的把握能力Q对原始业务模型q行归纳Q整理，抽象Q重构，以徏立一个更高效Q合理，扩展性更强的模型。这个过E无法以步骤说明。或总后笔者会专门针对模型分析写点东西。另外除了模型，q至需要写业务架构文档、用例规U和补充用例规约三种文档。因为模型虽然可以较好的体现业务架构Q但很不好表达业务规则和非业务需求，q些需要在文档中说明。例如用例的前置条g和后|条件就是一U业务规则。读者可以在RUP文档中找到这些文档的模板?img src ="http://www.tkk7.com/landy/aggbug/372626.html" width = "1" height = "1" />
]]>
Read part 1: Driving Design with Use Cases
Read part 2: Driving Design: The Problem Domain
Welcome to the third in a series of five articles that provides a prepublication look at the annotated example from the forthcoming book, Applied Use Case Driven Object Modeling(Addison-Wesley, 2001; tentatively scheduled for April). We're following the process detailed in our first book, Use Case Driven Object Modeling with UML (Addison-Wesley, 1999), as we dissect the design of an Internet bookstore. In this article, we show common mistakes, and then explain how to correct them.
Within the ICONIX process, one of the early steps involves building a use case model. This model is used to capture the user requirements of a new system (whether it's being developed from scratch or based on an existing system) by detailing all the scenarios that users will perform. Use cases drive the dynamic model and, by extension, the entire development effort.
Figure 1. The "Big Picture" for Use Case Driven Object Modeling |
Figure 1 shows where use case modeling resides within the "big picture" of the ICONIX process.
The Key Elements
The task of building use cases for your new system is based on immediately identifying as many as you can, and then establishing a continuous loop of writing and refining the text that describes them. Along the way, you will discover new use cases, and also factor out commonality in usage.
You should keep one overriding principle in mind during your effort to identify use cases: They should have strong correlations with material found in the system's user manual. The connection between each use case and a distinct section of your user guide should be obvious. It reinforces the fundamental notion that you are designing a system that will conform to the viewpoints of the users. It also provides a convenient summary of what "use case driven" means: Write the user manual, then write the code. If you're reengineering a legacy system, you can simply work backward from the user manual.
Once you have some text in place for a use case, it's time to refine it by making sure the sentences are clear and discrete, the basic format of your text is noun-verb-noun, and the actors and potential domain objects are easy to identify. You should also update your domain model—the subject of our previous article, "Driving Design: The Problem Domain" (Jan. 2001)—as you discover new objects and expand your understanding of the objects you'd previously found. And, it's important to determine all possible alternate courses of action for each use case wherever possible, an activity which should take up the majority of the time.
You can use several mechanisms to factor out common usage, such as error handling, from sets of use cases. This is usually effective, because breaking usage down to atomic levels will ease the analysis effort and save you lots of time when drawing sequence diagrams. Whether you use UML's generalization and includes and extends relationships, or OML's invokes andprecedes relationships, which we recommend in our book, your goal should be a set of small, precise, reusable use cases.
You should feel comfortable proceeding to the next phases of the development process when you've achieved the following goals:
- You've built use cases that together account for all of the desired functionality of the system.
- You've produced clear and concise written descriptions of the basic course of action, along with appropriate alternative courses of action, for each use case.
- You've factored out scenarios common to more than one use case, using whichever constructs you're most comfortable with.
The Top 10 Use Case Modeling Errors
Contrary to the principles we just discussed are a number of common errors that we have seen students make when they're doing use case modeling on their projects for the first time. Our "top 10" list follows.
10. Don't write functional requirements instead of usage scenario text. Requirements are generally stated in terms of what the system shall do, while usage scenarios describe actions that the users take and the responses that the system generates. Eventually, our use case text will be used as a run-time behavioral specification for the scenario we'll describe, and this text will sit on the left margin of a sequence diagram. We want to be able to easily see howthe system (shown with objects and messages) implements the desired behavior, as described in the use case text. So, we need to clearly distinguish between usage descriptions (behavior) and system requirements.
9. Don't describe attributes and methods rather than usage. Your use case text shouldn't include too many presentation details, but it should also be relatively free of details about the fields on your screens. Field names often match the names of attributes on your domain classes, which we discussed in January's article. Methods shouldn't be named or described in use case text because they represent how the system will do things, as opposed to what the system will do.
8. Don't write the use cases too tersely. When it comes to writing text for use cases, expansive is preferable. You need to address all of the details of user actions and system responses as you move into robustness analysis and interaction modeling, so you might as well put some of those details in your use cases. Remember also that your use cases will serve as the foundation for your user manual. It's better to err on the side of too much detail when it comes to user documentation.
7. Don't divorce yourself completely from the user interface. One of the fundamental notions of "use case driven" is that the development team conforms the design of the system to the viewpoints of the users. You can't do this without being specific as to what actions the users will perform on your screens. As we mentioned for item number nine, you don't need to talk about fields in your use case text, and you don't want to discuss the cosmetic appearance of your screens; however, you can let your prototypes, in whatever form they take, do that work for you. You do need to discuss those features of the user interface that allow the user to tell the system to do something.
6. Don't avoid explicit names for your boundary objects. Boundary objects are the objects with which actors will interact. These frequently include windows, screens, dialogs and menus. In keeping with our theme of including ample detail and being explicit about user navigation, we submit that it's necessary to name your boundary objects explicitly in your use case text. It's also important to do this because you will explore the behavior of these objects during robustness analysis (the subject of the next article in this series), and it can only reduce ambiguity and confusion to name them early.
5. Don't write in the passive voice, using a perspective other than the user's. A use case is most effectively written from the user's perspective as a set of present-tense verb phrases in active voice. The tendency of engineers to use passive voice is well-established, but use cases should state the actions that the user performs, and the system's responses to those actions. This kind of text is only effective when it's expressed in the active voice.
4. Don't describe only user interactions; ignore system responses. The narrative of a use case should be event- response oriented, as in, "The system does this when the user does that." The use case should capture a good deal of what happens "under the covers" in response to what the actor is doing, whether the system creates new objects, validates user input, generates error messages or whatever. Remember that your use case text describes both sides of the dialog between the user and the system.
3. Don't omit text for alternative courses of action. Basic courses of action are generally easier to identify and write text for. That doesn't mean, however, that you should put off dealing with alternative courses until, say, detailed design. Far from it. In fact, it's been our experience that when important alternative courses of action are not uncovered until coding and debugging, the programmer responsible for writing or fixing the code tends to treat them in ways that are most convenient for him. Needless to say, this isn't healthy for a project.
2. Don't focus on something other than what is "inside" a use case, such as how you get there or what happens afterward. Several prominent authors, such as Alistair Cockburn and Larry Constantine, advocate the use of long, complicated use case templates. Spaces for preconditions and post-conditions are generally present on these templates. We like to think of this as the 1040 "long form" approach to use case modeling, in comparison to the 1040EZ-like template that we advocate (two headings: Basic Course and Alternate Course). You shouldn't insist on using long and complex use case templates just because they appeared in a book or article. 
1. Don't spend a month deciding whether to use includes or extends. In our years of teaching use case driven development, we've yet to find a situation where we've needed more than one mechanism for factoring out commonality. Whether you use UML's include construct, or OML's invoke and precede mechanisms, or something else that you're comfortable with, doesn't matter; simply pick one way of doing things and stick with it. Having two similar constructs is worse than having only one. It's just too easy to get confused—and bogged down—when you try to use both. Don't spin your wheels.
Figure 2 shows use case text that contains violations of five of the top 10 rules.
Did you spot the violations?
- Use case one is too terse. There is no reference to what kind of information the customer enters, nor to the page he or she is looking at. The text doesn't explain what is involved in validating the data that the customer entered. And the use case doesn't describe how the customer needs to respond to an error condition.
- Use case two doesn't have explicit names for the relevant boundary objects.
- Use case three reveals how useless it can be to obsess about using a complicated use case template. The name of the use case expresses the goal clearly enough; the content of the basic course will make the stated precondition and postcondition redundant.
- Use case four lacks alternate courses, even though it should be fairly clear from the context that some validation needs to occur, and that there are several possible error conditions (for instance, the system can't find the e-mail address, or the password that the customer entered doesn't match the one that is stored).
- Use case five doesn't specify how the system responds when the customer presses the update button.
Figure 3 shows the use case text with the mistakes corrected.
Our next article will demonstrate how to do robustness analysis in order to tighten up use cases and make it easier to head into detailed design. See you next month.
Figure 2. The 1040 "Long Form" Approach to Use Cases |
Figure 3. The 1040EZ Approach to Use Cases |
]]>
Read Part 1: Driving Design with Use Cases
Welcome to the second in a series of five articles that provide a pre-publication look at the annotated example from our forthcoming book Applied Use Case Driven Object Modeling(Addison-Wesley, 2001; tentatively scheduled for April). We're following the process detailed in our first book, Use Case Driven Object Modeling with UML (Addison-Wesley, 1999), as we dissect the design of an Internet bookstore.
The focus of this article is domain modeling. The term "problem domain" refers to the area that encompasses real-world things and concepts related to the problem that the system is being designed to solve. Domain modeling is the task of discovering "objects" (classes, actually) that represent those things and concepts.
You may wonder why we're starting a series on use case driven object modeling by writing about the seemingly unrelated subject of domain modeling. The reason is that we write our use cases in the context of the object model (which we'll discuss in next month's article), instead of from an abstract, pure user viewpoint. This process allows us to connect the static and dynamic portions of the model, which is essential if we're going to drive our application design forward from the use cases. The domain model serves as a glossary that the writers of use cases can use in the early stages of that effort.
Within the ICONIX process, domain modeling involves working outward from the data requirements to build a static model of the problem domain relevant to the proposed system. This inside-out approach contrasts with the outside-in approach we take toward user requirements, which we'll describe in the third article in this series. (The fourth article, about robustness analysis, will describe how the domain modeling and use case development paths merge.)
Figure 1. The "Big Picture" for Use Case Driven Object Modeling |
Figure 1 illustrates where domain modeling resides within the "big picture" for the ICONIX process.
Key Elements of Domain Modeling
The first thing you must do when building a static model of your system is find appropriate classes that accurately represent the real abstractions that the problem domain presents. If you execute this activity well, you will not only have a solid foundation on which to build the system, but also excellent prospects for reuse by systems that will be designed and built over time.
The best sources of classes are likely to be the high-level problem statement, lower-level requirements and expert knowledge of the problem space. To get started, lay out as many relevant statements from these areas (and even others, such as marketing literature) as you can find, and then circle, or highlight, all the nouns and noun phrases. As you work, refine the lists; gradually, nouns and noun phrases will become objects and attributes, while verbs and verb phrases will become operations and associations. Possessives ("its," "ours" and "theirs") tend to indicate that nouns should be attributes, rather than objects.
Next, sift through your list of candidate classes and eliminate unnecessary items. Look for classes that are redundant, irrelevant, incorrect or vague. Unessential classes may also represent concepts outside the scope of the model, or represent actions even though they're phrased as nouns: For example, Order Processor represents the nounification of the verb pharse, "process order."
You should also make some initial decisions about generalization ("kind of" or "is a" relationships among classes) while building your class diagram(s). If you need to, and you're comfortable doing so at this stage, generalize to more than one level of a subclass. Remember to look for kind-of statements that are true in the real world. Domain modeling is also the appropriate area for decisions about aggregations ("part of" or "has" relationships among classes).
Finally, much like an entity-relationship diagram (ERD), your domain model, updated to show associations—the static relationships between pairs of classes—should be a true statement about the problem space, independent of time (that is, static). This model serves as the foundation of your static class model.
The Top 10 Domain Modeling Errors
The flip side of the principles that we just discussed are a number of common errors that our students make when they're doing domain modeling for their projects. Our "top 10" list follows:
10. Don't immediately assign multiplicities to associations. Make sure that every association has an explicit multiplicity. Some associations on a class diagram represent one-to-one relationships, while others represent one-to-many relationships. These are both called multiplicities. However, you can avoid dealing with multiplicity altogether during domain modeling—it chews up time and can be a major cause of analysis paralysis, which we'll signal with this symbol. 
9. Don't do such an exhaustive noun and verb analysis that you pass out along the way. Kurt Derr's Applying OMT (SIGS Books, 1995) is a good source of information about "grammatical inspection." If you follow Derr's advice to the letter, however, you'll likely reach such an extreme level of detail, at such a low level of abstraction, with regard to your objects, that you can't breathe. Use this technique to get your object discovery started, but take care not to get carried away.
8. Don't assign operations to classes without exploring use cases and sequence diagrams.Take a minimalist approach to defining operations during domain modeling. In fact, don't assign any operations to classes during domain modeling, because there isn't enough information available with which to make good design decisions about operations at that stage. Wait until you begin interaction modeling, before you assign operations to classes.
7. Don't optimize your code for reusability before making sure you've satisfied the user's requirements. The more general your objects and classes, the higher the probability that you'll be able to reuse those objects and classes for other projects. A complete class is one that is theoretically reusable in any number of contexts. However, in order to achieve reusability and completeness, you must consider both attributes and operations, and we just told you why you shouldn't be assigning operations to classes during domain modeling. So don't worry too much about making classes reusable when you're doing high-level class diagrams.
6. Don't debate whether to use aggregation or composition for each of your part-of associations. Grady Booch's original descriptions of "has by reference" relationships morphed into aggregation within UML. Similarly, "has by value" became a "strong" form of aggregation called "composition" within which a "piece" class is "owned by" one larger class. Trying to differentiate between these two during a domain modeling effort is a definite way to do some serious tail-chasing. We much prefer to focus on simple aggregation during domain modeling. Aggregation versus composition is a detailed design issue.
5. Don't presume a specific implementation strategy without modeling the problem space. As part of the ongoing refinement of your domain model, you should remove anything that clearly states an action rather than a dependency or that is specifically related to implementation. Don't introduce things on your high-level class diagrams that represent commitments to specific technologies, whether it's a relational database or a particular kind of server. Leave implementation issues to implementation.
4. Don't use hard-to-understand names for your classes, like cPortMgrIntf, instead of intuitively obvious ones, like PortfolioManager. Doing domain modeling up front helps everyone on the project team agree on what classes should be called. The more obvious the class names, the easier that task will be. Save acronyms and other kinds of abbreviations (if you insist on having them) for implementation.
3. Don't jump directly to implementation constructs such as friend relationships and parameterized classes. UML offers lots of opportunities to add what we call "Booch stuff" to class diagrams. This includes constructs that come more or less directly from C++, such as abstract and parameterized classes and friend relationships. These are more relevant to the solution space than to the problem space, though, and the focus of domain modeling should definitely be the problem space.
2. Don't create a one-for-one mapping between domain classes and relational database tables. If you're reengineering a legacy system that uses a relational database, the tables within that database are likely to be an excellent source of domain classes. However, be careful not to just bring them over to your static model wholesale. Relational tables can have lots of attributes that might not belong together in the context of an object model. You should use aggregation to factor groups of attributes into "helper" classes, which contain attributes and operations that are relevant to more significant classes.
1. Don't perform "premature patternization," which involves building cool solutions, from patterns, that have little or no connection to user problems. Patterns often become visible during robustness analysis. As we'll explore in the fourth article of this series, there are two strategies, "control in the screen" and "use case controller," that lend themselves to discovering patterns connected to use cases. Looking ahead to interaction modeling, design patterns can be highly useful in the context of sequence diagrams and design-level class diagrams. However, domain modeling is not the time to start thinking in terms of patterns.
Figure 2. A Flawed Class Diagram |
Figure 2 shows a class diagram that violates five of the top 10 rules.
Did you spot the violations?
- The cBinaryTree class is a parameterized class (also known as a template class within UML). This violates rule number three. There is no good reason to define an implementation construct such as a binary tree at this stage of modeling.
- The name of the cSessionBeanShpngCrt class indicates that the modeler has decided to represent the concept of a shopping cart using a session Enterprise Java Bean (EJB). This violates rule number five. Robustness analysis, which we'll discuss in the fourth article in this series, is the appropriate stage to explore how to map classes to Java Beans and so on.
- This class also has a composition relationship with the Order class. This violates rule number six. The modeler has committed to the idea that an order disappears when the shopping cart object to which it belongs is destroyed. This may or not make sense in the long run, but it's certainly too soon to be thinking along those lines.
- The cLoginMgr class has an operation named verifyPassword. This violates rule number eight. It's too early to make decisions about which operations go on which classes, and besides, chances are good that the operation belongs on the Login Info class anyway.
- The names of the two classes we just discussed should be Shopping Cart and Login Manager. The current names both violate rule number four.
Figure 3. A Corrected Class Diagram |
See the diagram in Figure 3 to see how the mistakes are corrected.
Our next article will discuss how to write small and concise use cases that capture functional requirements in terms of user actions and system responses in a way that's easy for readers to understand at a glance. See you then.
]]>
We need to see more use case and Unified Modeling Language examples" is a demand we hear fairly often these days. Although we present a fairly extensive example in our first book, Use Case Driven Object Modeling with UML (Addison-Wesley, 1999), we recently convinced Addison-Wesley to let us produce a companion workbook, in which we will dissect the design of an Internet bookstore, step-by-step, in great detail. This will involve showing many common mistakes, and then showing the model with its mistakes corrected.
This article is the first in a series of five that will provide a prepublication look at the annotated example from the workbook (to be called Applied Use Case Driven Object Modeling, conveniently enough) as it evolves. We'll be following the process detailed in our book (also known as the ICONIX process), which sits somewhere between the very large Rational Unified Process (RUP) and the very small Extreme Programming (XP) approach.
The ICONIX process is use case driven, like RUP, but lacks a lot of the overhead that RUP brings to the table. It's also relatively small and tight, like XP, but it doesn't discard analysis and design like XP does. This process also makes streamlined use of UML while keeping a sharp focus on the traceability of requirements. And, the process stays true to Jacobson's original vision of what "use case driven" means, in that it results in concrete, specific, readily understandable use cases that a project team can actually use to drive the development effort.
Each of the articles that follow this one will address an essential aspect of the process by focusing on one of the four critical diagrams used in the Iconix process. These four articles will have the same basic look and feel, with these shared elements:
- A "top 10" list that describes modeling errors to avoid.
- A diagram that shows two or three violations of these top 10 rules, as committed by students in classes that we've taught.
- Another diagram that shows corrections of the erroneous material.
Best of Breed
Figure 1 shows the "big picture" for the process. The diagram portrays the essence of a streamlined approach to software development that includes a minimal set of UML diagrams and some valuable techniques that take you from use cases to code quickly and efficiently. The approach is flexible and open; you can always select from the other aspects of UML to supplement the basic materials.
Figure 1. The "Big Picture" for Use Case Driven Object Modeling
The diagram portrays the essence of a streamlined approach to software development that includes a minimal set of UML diagrams and some valuable techniques that take you from use cases to code quickly and efficiently. |
The second article will discuss domain modeling. This is the task of discovering classes that represent the things and concepts related to the problem that a system is being designed to solve. We'll describe how the domain model serves as a glossary of terms that people can use in writing use cases.
Domain modeling involves working outward from the data requirements to build a static model of the problem domain relevant to the proposed system. We'll point out how the approach emphasizes domain modeling more than RUP, and certainly more than XP.
The third article will discuss how to write use cases that detail the scenarios that the users will be performing. We'll describe how to write complete and unambiguous use cases that describe individual aspects of system usage without presuming any specific design or implementation.
Use case modeling involves working inward from the user requirements to start building adynamic model of the solution space for the proposed system. We'll talk about how use cases, by extension, drive the entire development effort.
The Forgotten Diagram
The fourth article in the series will discuss robustness analysis, a practice that originated with Ivar Jacobson but was dropped from the Rational implementation of UML. This involves analyzing the narrative text of use cases, identifying a first-guess set of objects that will participate in those use cases, and classifying these objects based on the roles they play.
- Boundary objects are what actors use in communicating with the system.
- Entity objects are usually objects from the domain model.
- Controllers serve as the "glue" between boundary objects and entity objects.
We'll show how robustness analysis, which serves as preliminary design within the process, provides the missing link between analysis and detailed design.
The fifth and last article will discuss interaction modeling, the phase in which people build the threads that weave their objects together and enable them to start seeing how the new system will perform useful behavior. We'll demonstrate how to build sequence diagrams, which enable designers to perform three key tasks:
- Allocate behavior among boundary objects, entity objects, and controllers that will become full objects in the model.
- Show the detailed interactions that occur over time among the objects associated with each use case.
- Finalize the distribution of operations among classes.
We'll explain how the detailed, design-level class diagrams that result from interaction modeling represent a suitable foundation for moving into the coding phase of a project.
We'd like to point out three significant features of this approach.
First, it's iterative and incremental. Multiple iterations occur between developing the domain model and identifying and analyzing the use cases. Other iterations exist, as well, as the team proceeds through the life cycle. The static model gets refined incrementally during the successive iterations through the dynamic model (composed of use cases, robustness analysis and sequence diagrams). Please note, though, that the approach doesn't require formal milestones and lots of bookkeeping; rather, the refinement efforts result in natural milestones as the project team gains knowledge and experience.
Second, the approach offers a high degree of traceability. At every step along the way, you refer back to the requirements in some way. There is never a point at which the process allows you to stray too far from the user's needs. Traceability also refers to the fact that you can track objects from step to step as analysis melds into design.
Third, the approach offers streamlined usage of UML. The steps that we'll describe in the upcoming articles represent a "minimalist" approach-they comprise the minimal set of steps that we've found to be necessary and sufficient on the road to a successful OO development project. By focusing on a subset of the large and often unwieldy UML, a project team can also head off "analysis paralysis" at the pass.
E-Commerce Example
We'll demonstrate these aspects of the ICONIX process in the context of an on-line bookstore. The focus will be on the customer's view of the system.
Article two will describe how to build a domain model that has loosely coupled classes, each of which does one thing well.
Article three will discuss how to write small, concise use cases that capture functional requirements in terms of user actions and system responses in a way that's easy for readers to understand at a glance.
Article four will demonstrate how to do robustness analysis in order to tighten up use cases and make it easier to head into detailed design.
Article five will explore sequence diagrams, which we'll use to allocate the behavior specified by use cases to the objects mentioned in those use cases.
See you next month.
http://drdobbs.com/184414677
]]>
by Kendall Scott and Doug Rosenberg
Read part 1: Driving Design with Use Cases
Read part 2: Driving Design: The Problem Domain
Read part 3: Top Ten Use Case Mistakes
Welcome to the fourth in a series of five articles that provides a pre-publication look at the annotated example from the forthcoming Applied Use Case Driven Object Modeling. (Addison-Wesley, 2001; tentatively scheduled for June). We're following the process detailed in our first book, Use Case Driven Object Modeling with UML (Addison-Wesley, 1999), as we dissect the design of an Internet bookstore. This article is the third one in which we show common mistakes, and then explain how to correct them.
This article focuses on robustness analysis, which involves analyzing the narrative text of use cases and identifying a first-guess set of objects that will participate in each use case, then classifying these objects into three types:
- Boundary objects, which actors use in communicating with the system.
- Entity objects, which are usually objects from the domain model (the subject of "Driving Design: The Problem Domain," Jan. 2001).
- Control objects (which we usually call controllers because they often aren't real objects), which serve as the "glue" between boundary objects and entity objects.Figure 1 shows the visual icons for these three types of objects.
Figure 1. Visual Icons of Three Stereotypes |
Figure 2. Purpose of Robustness Analysis |
Figure 3. The "Big Picture" for Use Case Driven Object Modeling |
Figure 4. The Essential Roles of Robustness Analysis |
Within the ICONIX process, this simple but highly useful technique serves as a crucial link between analysis—the what—and design—the how, as shown in Figure 2. Figure 3 shows where robustness analysis resides within the "big picture" for the ICONIX process.
The Key Elements
Robustness analysis plays several essential roles within the ICONIX process. Note that you will refine both your use case text and your static model as a result of robustness analysis, as shown in Figure 4.
Robustness analysis provides a sanity check by helping you make sure that your use case text is correct and that you haven't specified system behavior that is unreasonable—or impossible—given the set of objects you have. This refinement of the use case text changes the nature of that text from a pure user manual perspective to a usage description in the context of the object model.
It also provides a completeness and correctness check by helping you determine if the use cases address all necessary alternate courses of action, which we discussed in the third article in this series, "Top Ten Use Case Mistakes" (Feb. 2001). In our experience, the time spent drawing robustness diagrams toward this end, and also toward the end of producing text that adheres to some well-defined guidelines, is invariably made up three- or four-fold in time saved in drawing sequence diagrams.
Robustness analysis enables the ongoing discovery of objects; a crucial step because you almost certainly missed some objects during domain modeling. You can also address object naming discrepancies and conflicts before they cause serious problems. And, robustness analysis helps you ensure that you've identified most of the major domain classes before starting sequence diagrams.
Finally, robustness analysis fills the role of preliminary design, by closing the gap between analysis and detailed design.
Let's take a closer look at the three stereotypes that we apply to objects during robustness analysis.
Boundary objects are the objects with which the actors (for instance, the users) will be interacting in the new system. These frequently include windows, screens, dialogs and menus. If you have a GUI prototype in place, you can see what many of your primary boundary objects will be, and if you follow the guidelines we gave you last month, you can also easily pick boundary objects out of your use case text.
Entity objects often map to the database tables and files that contain the information that needs to "outlive" use case execution. Some of your entity objects are "transient" objects, such as search results, that "die" when the use case ends, and many of your entity objects will come from your domain model.
Control objects (controllers) embody much of the application logic and serve as the connecting tissue between the users and the stored data. This is where you capture frequently changing business rules and policies, and localize changes to these objects without disrupting your user interface or your database schema down the line. Once in a while (perhaps 20 percent of the time), controllers are "real objects" in a design, but controllers usually serve as placeholders to assure that you don't forget any functionality and system behavior required by your use cases.
You perform robustness analysis for a use case by walking through the use case text, one sentence at a time, and drawing the actors, the appropriate boundary, entity objects and controllers, and the connections among the various elements of the diagram. You should be able to fit the basic course and all of the alternate courses on one diagram. Four basic rules apply:
- Actors can only talk to boundary objects.
- Boundary objects can only talk to controllers and actors.
- Entity objects can only talk to controllers.
- Controllers can talk to boundary objects and entity objects, and to other controllers, but not to actors
Figure 5. Robustness Analysis Rules |
Keep in mind that both boundary objects and entity objects are nouns, and that controllers are verbs. Nouns can't talk to other nouns, but verbs can talk to either nouns or verbs. Figure 5 summarizes the robustness diagram rules.
Anyone who reviews a robustness diagram should be able to read a course of action in the use case text, trace his finger along the associations on the diagram, and see a clear match between text and picture. You will probably have to rewrite your use case text as you do this, to remove ambiguity and to explicitly reference boundary objects and entity objects. Most people don't write perfect use case text in the first draft.
In addition to using the results of robustness analysis to tighten up the use case text, you should also continuously refine your static model. The new objects you discover drawing the diagrams should become part of your class diagrams when you discover them, and this is also the right time to add some key attributes to your more significant classes.
Top 10 Robustness Analysis Errors
Many of the students we've taught make a number of errors when they're doing robustness analysis for the first time. Our "top 10" list of solutions to common errors follows.
10. Don't violate the robustness diagram rules. These rules are in place primarily to get your text into noun-verb-noun format and to help ensure that you don't start allocating behavior to objects before you have enough information to make good design decisions. (We'll talk more about behavior allocation in our upcoming article on sequence diagrams.) The rules about boundary objects are in place to ensure that you explicitly specify the boundaries of the system, outside of which reside the actors involved in your use cases.
9. Use robustness analysis to help you use a consistent format for your use case text. The boundary object-controller-entity object pattern tends to appear on lots of robustness diagrams. This pattern closely correlates with the subject-verb-object pattern of basic English sentences. You should use robustness analysis to make the text of your use cases stylistically consistent among themselves to the largest extent you can, which greatly improves their readability and maintainability.
8. Include alternate courses on robustness diagrams. You need to perform robustness analysis on all of your use case text, not just the basic courses. Much of the interesting behavior of a system occurs in the context of alternate courses, so it's important to analyze that behavior as part of your modeling efforts. Robustness analysis can also help you discover new alternate courses, especially when you draw controllers with labels such as Verify and Validate.
7. Use robustness analysis to ensure consistency between class names on class diagrams and in use case text. Specifying use case text in the context of the object model is the magic formula you need to build useful sequence diagrams. By naming your boundary objects and entity objects in your use cases, you take a healthy step toward getting your sequence diagrams off to a good start, by simply drawing those objects across the top of the sequence diagram for each use case.
6. Don't allocate behavior to classes on your robustness diagrams. As we mentioned earlier, controllers serve as placeholders for functionality and system behavior. You should not start assigning methods to classes on a robustness diagram, because you're not likely to have enough information. Make decisions about behavior allocation using sequence diagrams.
5. Don't include too few or too many controllers. We like to see between two and five controllers on a robustness diagram. If you only have one controller per use case, you're likely to have a lot of very small use cases, each of which don't really describe enough behavior. On the other hand, if you have more than 10 controllers on one diagram, you should consider splitting your use case up into more manageable chunks.
4. Don't take too much time trying to perfect robustness diagrams. The robustness diagram serves as a "booster-stage engine" that gets the process of driving use cases forward into an object-oriented design off the ground. Robustness analysis helps us discover objects, allocate attributes, and check the use case text for completeness and correctness. But once we've accomplished the overall mission, we don't need to maintain the work product. It's a means to an end, not an end in itself.
3. Don't try to do detailed design on robustness diagrams. The concept of throwaway diagrams is useful in connection with preliminary design; it's not a useful concept when it comes to detailed design. Sequence diagrams are the appropriate place for detailed design. Robustness analysis should be a quick pass across all of the scenarios you're going to build, in order to provide maximum value to your project. If your preliminary design takes as long as detailed design, you'll lose the benefits of this quick sanity check.
2. Perform a visual trace between the use case text and the robustness diagram. We strongly recommend that you have a peer review for all of your use case text and robustness diagrams, with each reviewer performing the finger trace technique that we described earlier. You should not consider your use case done until it passes the simple visual trace test. When you've reached the point where each of your use cases pass the test, the next step-drawing sequence diagrams-will be easier for you to perform than if you were starting from your use case text alone.
1. Update your static model. You must update your domain model before you can consider yourself done with robustness analysis and ready to move on to interaction modeling using sequence diagrams. After all, you can't allocate behavior to classes that don't appear in your static model.
Figure 6 shows a robustness diagram that contains violations of four of the top 10 rules.
Figure 6. Incorrect Robustness Diagram |
Did you spot the violations?
- The Home Page boundary object is talking to the Login Page boundary object and the Account Table entity object, violations of rule 10.
- The Account Table object has a method assigned to it. This violates rule six.
- There aren't any alternate courses (what happens if the passwords don't match, for instance?) associated with the Validate Login Info control object, a violation of rule eight.
- The Intercept Request object is a construct that belongs to detailed design. This violates rule three.
Figure 7 shows the robustness diagram with the mistakes corrected.
Figure 7. Corrected Robustness Diagram |
Our next article will demonstrate how to draw sequence diagrams, which reside at the core of detailed design within the ICONIX process. See you next month.
Note: denotes analysis paralysis.
]]>
]]>
http://code.google.com/p/spring-social-plugins/
]]>
如何解决上文提到的鉴定标准中的问题呢Q我认ؓ{案是MDD?/p>
用一个实际的例子来表qC下思\Q?/p>
在CRMpȝ有个订单处理模块Q其提供了订单管理、订单流E执行、工单管理等功能Q营业员通过界面提交一个订单请求，如果订单h通过业务规则的校验，则会创徏一个订单对象，订单对象的创Z触发订单程的创建，订单程{的过E中Q会在各个节点创建工单，也会调用其它子系l开通服务，比如调用物流发货。订单流E完成后Q订单对象的状态也完成。实际的pȝ比这个要复杂Q这里仅仅ؓ了阐q思\Q做适当的简化?/p>
从上面的例子Q我们可以识别出几个模型:订单、工单、订单流E，订单、工单、订单流E都是stateful的、其state的变更会D其它对象的状态变更或者服务的执行?/p>
在展现层Q展现各个模型是有章法的Q比如创单的界面L一LQ处理工单的界面也L一LQ展现订单的界面也L一L。因此，我们可针Ҏ定的对象的某U需要展现的状态，提供合适的展示构gQWEB TAGQ来展示它?/p>
在持久层Q因为对象L持久化到一张表当中的，因此Q可用一些ORM的框架来持久化对象，而不是开发h员针Ҏ个场景去写SQLQ复杂的兌查询可以使用cHQL?/p>
各对象之间的兌操作通过事g驱动?/p>
举一个订单创建的例子Q?/p>
1、开发做的工作：
1Q用元数据定义订单的数据结构，包含持久化元数据、基本属性元数据、字典元数据Q?/p>
2Q定义订单状态机Q以及状态变q的规则Q?/p>
3Q徏模订单处理流E；
4Q定义订单请求处理规则流Qƈ发布Z个受理订单请求的服务Q?/p>
5Q开发订单创建界面，使用订单WEB构g来展C单对象；
6Q定义事Ӟ以及事g的监听服务；
2、系l执行流E：
1Q营业员打开订单创徏界面Q系l获取订单对象的元数据，生成订单创徏面Q?/p>
2Q营业员点击订单创徏界面的提交按钮，调用受理订单h的服务；规则执行，如果规则校验错误Q则q回错误Q如果成功，则创单，q回成功Q?/p>
3Q因创徏订单Q导致订单的状态变为创建状态，触发订单创徏事gQ?/p>
4Q订单创建的监听服务程服务接收CӞ触发订单处理程的创建；
5Q流E执行的q程中编排第三方pȝ服务Q流E执行结束后Q触发订单流E结束事Ӟ程l束事g的监听服务订单管理接收到事gQ触发状态机变迁Q订单状态变为完成?/p>
上述开发做的工作全部可通过配置完成。后l如果增删字D，修改元数据即可，要增删改业务规则Q调整业务规则即可，要调整实体状态，修改实体状态机卛_?/p>
业务q_要致力于对状态机、业务流E、SEP、元数据、领域化的WEB构g的实玎ͼq将其有机整合?/p>
写的比较乱，q几天再整理一下。。?/p>
]]>
]]>
This chapter provides an overview of the JavaFX™ Script programming language. At a high level, this chapter describes the programming language's main features, saving detailed coverage of specific constructs for subsequent chapters. This book is intended for designers and developers of rich Internet client applications and elements, that run in web pages, as Java™ Web Start software, or as traditional desktop applications. Its content assumes the reader is familiar with either the JavaScript or Java™ programming language, or both. While this document does not define a formal language specification, it can be considered a complete reference for all currently supported language features.
本章提供了JavaFx脚本~程语言的一个概览。本章概qCq门~程语言的主要特性，后箋章节会详细介绍q些Ҏ的l节。本书适用于副Internet客户端应用的设计者和开发者。这些应用可以作为Java Web Start软gq行在网中或者作Zl的桌面应用。本书假定读者熟悉了javascript或java~程语言或者两者都熟悉。但是本书ƈ不是正式的语a规范Q可仅仅做ؓ当前JavaFx支持的语aҎ的一个完整的参考?br />
The JavaFX Script programming language has the following distinctions:
JavaFX脚本~程语言有如下的语言特色Q?br />
- Uses a declarative syntax for specifying Graphical User Interface (GUI) components, enabling a developer's code to closely match the actual layout of the GUI.
- 可用声明式的语法编写图形界面组Ӟ使得开发者的代码非常接近于GUI的实际布局?br />
- Uses declarative data binding and incremental evaluation, enabling easy creation and configuration of individual components. Application data and GUI components are automatically synchronized.
- 使用声明式的数据l定和incremental evaluation(不知道如何翻?, 使得创徏和配|组件变得简单。应用数据和GUIlg自动同步?br />
- Is statically typed, having most of the same code structuring, reuse, and encapsulation features that enable creating and maintaining very large programs in the Java programming language.
- 它是一门静态类型的、绝大部分代码结构、复用和装Ҏ跟Java~程语言一P可用来创建和l护大型应用?br />
- Works with all major IDEs, including the NetBeans IDE, the reference implementation IDE for software development with the Java programming language.
- 支持LIDEQ包括NetBeans IDEQNetBeans IDE是用Java~程语言q行软g开发的IDE参考实现?br />
- Is capable of supporting GUIs of any size or complexity.
- 能够支持Ҏ大小和复杂度的GUI?br />
- Makes it easier to use Swing.
- 它Swing~程变得更容?br />
The following sections present a quick tour of the JavaFX Script programming language. These sections provide a general introduction to its core syntax and capabilities, comparing and contrasting to the Java programming language where appropriate. Each topic is then covered in greater detail in subsequent chapters.
接下来的节是JavaFX脚本~程语言的一个快速指南，介绍了JavaFx的关键语法和能力Qƈ且比较了它跟java~程语言之间的差异，每个主题在后箋的章节中详细的介l?br />
Scripts
In the JavaFX Script programming language, a "script" is one or more declarations or expressions. Evaluating the script evaluates the declarations or expressions, in order:
在JavaFx中，“script”是一个以上的声明z表辑ּ。执行脚本就是顺序执行脚本中的声明或表达式：
var ten : Integer = 10;
java.lang.System.out.println("Twice {ten} is {2 * ten}.");
This prints out:
上面的语句会打印出：
Twice 10 is 20.
Unlike an application written in the Java programming language, a script need not contain any class definitions or functions.
不想用java写的应用Q脚本不需要包含class定义或者函数?br />
Classes
Class definitions share many similarities with the Java programming language, but some differences are notable. State, for example, is information stored in attributes, not fields. Behavior is exposed through functions, not methods. The following example defines a simple Rectangle class that demonstrates the basic syntax of each.
class Rectangle {
attribute width: Integer;
attribute height: Integer;
function grow(): Void {
grow(1);
}
function grow(amount: Integer): Void {
width += amount;
height += amount;
}
}
The JavaFX Script programming language supports multiple inheritance, making it possible to inherit from more than one class.
Classes are covered in detail in Chapter 2
Attributes and Functions are covered in detail in Chapter 3
Objects
Object literals provide a simple syntax for class instantiation. The following code creates a single instance of the Rectangle class defined previously, initializing its width and heightattributes to 100. (Note that new is not needed.)
Rectangle {
width: 100
height: 100
}
To store a reference to this object, use the var keyword:
var myRect = Rectangle {
width: 100
height: 100
}
Objects are covered in detail in Chapter 2 .
Variables and basic data types are covered in detail in Chapter 4
Expressions and Operators
Like other programming languages, the JavaFX Script programming language supports expressions and operators.
Chapter 5 discusses the expressions and operators available in the JavaFX Script programming language.
Sequences
A sequence holds an ordered list of objects. This is roughly analogous to Java programming language arrays. Both hold multiple values and are accessed by index starting at 0.
var week = ["Monday","Tuesday","Wednesday","Thursday",
"Friday","Saturday","Sunday"];
var mon = week[0];
var wed = week[2];
var fri = week[4];
Sequence slices are also supported:
var week = ["Monday","Tuesday","Wednesday","Thursday",
"Friday","Saturday","Sunday"];
var weekdays = week[0..4]; // first slice
var weekend = week[5..6]; // second slice
Chapter 6 covers the basics of declaring sequences, while Chapter 7 focuses on using sequences.
Data Binding
Data binding provides a simple syntax for synchronizing the state of multiple objects. When two objects are bound to each other, the second object's value automatically changes whenever the first object is updated. A common use of data binding is to keep GUI components synchronized with their underlying data.
import javafx.application.Frame;
import javafx.application.Stage;
import javafx.scene.text.Text;
var myString = "Hello World!";
Frame {
width: 50
height: 50
visible: true
stage: Stage {
content: Text {
content: bind myString
}
}
}
// If some other part of code changes myString
// then the GUI's text will automatically change
// as well.
Data Binding is covered in detail in Chapter 8 .
Triggers
Triggers are blocks of code that run when certain conditions are true. For example, you may want to be alerted if an attribute's value has been set to something that is inappropriate. The following example shows the basic trigger syntax:
import java.lang.System;
ReplaceDemo {
mySensitiveData: "Will anyone notice?"
}
class ReplaceDemo {
attribute mySensitiveData: String
on replace {
System.out.println("I noticed a change!");
};
// application-specific safeguarding code would go here
}
Triggers are covered in detail in Chapter 9 .
]]>
]]>
“做事情关注目标就行了Q一些旁枝末节不必在意。批评别Z要讲艺术Q需要让别h感受到是在真正的帮他Q不然就会适得其反?#8221;
l细咀|q些工作l验在生zM也是适用的?br /> 改变自己Q就从nҎ一件小事做赗?br /> 一个hQ能力不够，只能是现在q个样子。若有不满，先从提升自n能力开始?br />
]]>
爱情的意?br>像风没有理由
轻轻吹着?br>谁爱谁没?br>所谓的对与?br>不管旉
说着我们在一h多坎?br>我不敢去证实
׃两个?br>不是对自q?br>也不是讽?br>别h都在说我其实很无?br>q样的感情被认定很放?br>我很不服
我还在想着那g?br>如果你已l不能控?br>每天x一?br>如果你因为我而诚?br>如果你看我的电媄
听我qcd
如果你能带我一h?br>如果你决定跟随感?br>为爱勇敢一?br>如果你说我们有彼?br>如果你会开始相?br>q般恋爱心情
如果你能l我如果的事
我只要你一?font style="color: #e10900;">如果的事
我会奋不n地去׃
]]>
]]>