亚洲成a人片7777,亚洲av综合av一区二区三区,亚洲av无码成人影院一区

Sat, 21 Jul 2012 04:30:00 GMT

本�h曄��阅读�q�《��Y件架构设计》一书的�W�一版，��M��之后�Ҏ��构设计的�Ҏ��、流�E�有了更深刻的认识，也对我后�l�的工作起了非常大的指导作用。最�q�从ITEye上了解到温昱先生��Z��《��Y件架构设计》一书的�W�二版，赶紧下了��L��M��一下，感觉�W�二版相比第一版，在概��c��方法、流�E�、实践几个方面的指导性更��Z��Q�实在是�E�序员升�U�架构师必备良书�Q?/p>

下面��Z��我实际经历的一个项目，�l�合寏V��Y件架构设计》一书的理解�Q�谈一下质量属性的设计�?/p>

首先介绍一下项目背景，某大型电信解��x��案提供商向全球电信运营商提供某��Y件系�l�，因不同的�q�营商需求有差别�Q�需要投入大量的人力物力�Ҏ��个特定的�q�营商进行客户化定制�Q�成本较高，��Z��降低定制成本�Q�该提供商将交付�l�织切分��责通用版本的组�l�A和负责针对特定局点定制的交付�l�织B�Q�且成立了一个项目专门提升该软�g�pȝ��的可定制性，以实现这�U�分�U�交付，降低定制成本�?/p>

��目启动后，负责该项目的架构师凭借丰富的�l�验马上启动了架构设计，他从业界同类产品了解刎ͼ�业界��Z��提升定制能力采用了元数据驱动的架构风��|��于是马上开始了元数据驱动框架的设计�Q�设计好之后召集开发�h员和��理人员开了个沟通会�Q�会中，该架构师被两个问题难住了�Q?/p>

1�Q�有个定制开发�h员问�Q�如果基�U�版本升�U�了�Q�能否保证定制版本做的修改能够被直接�l�承�Q�在�q�个问题上，大家发生了激烈的争论�Q�架构设计团队认为有些场景可以，有些场景不可以，而定制开发�h员的理解跟架构设计团队的理解不一��P��最�l�该问题被搁�|�下来，后箋再论�?/p>

2�Q�管理�h员问�Q�对定制能力目标�Q�我们怎么��试和验证目标是否达成。这个问题比较毒�Q�一下子把架构设计团队问��M��Q�没人答得上来，于是被骂了一��ѝ�?/p>

问题在哪里？�Q�看了《��Y件架构设计》的�W?�?#8220;概念性架构设�?#8221;��p��扑ֈ��{�案。我认�ؓ的问题有�Q?/p>

1�Q�没有从�pȝ��各Actor的角度，分析定制用例�Q�导致重要定制场景遗漏，被问��L��时候自然就捉襟见肘�Q?/p>

2�Q�没有将定制能力目标分解到定制场景，��D��对设计缺乏度量，不知道设计到底能不能满��定制能力目标要求�Q�自然也回答不了“通用版本与定制版本的边界”�q�类的问题�?/p>

要怎么做呢�Q�？看了《��Y件架构设计》的�W?�?#8220;概念性架构设�?#8221;��p��扑ֈ��{�案。我认�ؓ�Q�应该遵从下面的步骤�Q�才能确保定制目标的达成�Q?/p>

1�Q�分析定制的Actor�Q�比如定制开发�h员，定制�q�维人员�{�；

2�Q�针对各Actor�Q�分析其定制用例�Q�如开发�h员增加一个业务、修改一个业务流�E�、增加一个业务实体字�D늭��{�；

3�Q�针�Ҏ��个用例，�l�合定制能力目标�Q�分析该Actor的工作流�E�，通过�q�一步的分析�Q�通用版本的边界（�pȝ��用例�Q�能够大致识别出来�?/p>

4�Q�再针对关键�pȝ��用例�Q�进一步��用分析对象进行鲁��分析；通过�q�一步，对元数据驱动框架的能力要求能明确下来�Q?/p>

5�Q�然后在�q�一步对元数据驱动框架进行细化设计；

通过�q�样一个系�l�的�Ҏ��和流�E�，我们才能保证做出�W�合业务目标的可定制性设计。其它类型的质量属性的设计�Ҏ��和流�E�也是类似的�?/p>

其实那个负责可定制性设计的架构设计团队不管是业务经验还是技术能力，都是比较扎实的，关键是没有掌握一个比较科学的设计�Ҏ��和流�E�。因此，�q�大�E�序员兄弟们在实�늚�同时�Q�一定不能忘了提升理论素养，�q�样才有利于更早的打破天花板�Q�获得更大的成功�?/p>

�q�途书�?/a> 2012-07-21 12:30 发表评论

Wed, 18 Jul 2012 13:19:00 GMT

当下�Q�SOA�q�个词已�l�深入�h心，几乎没有��Z��说自��p��计的应用是遵从SOA的�?/p>

很多人对SOA的理解就是分层、模块化、面向对象。。。这�U�理解对不对后面再说。先看一些问题：

我今天看了一个开发团队的开发工�E�包�l�构�Q�部分类的命名及�l�织产生了如下印象：

每个usecase是一�Ҏ��烟囱
烟囱与烟�׃��间连模型都没有共享。其实业务模型是有设计的�Q�主要是实现模型没有保持业务模型的结构特征，全部成了“值对�?#8221;�Q�开发�h员天天把�q�些值对象叫做领域对象�?/li>
有三层，是Struts帮忙定义的，三层分别�Ҏ��usecase分包

�q�也是我们宣�U�的SOA�pȝ��Q�！�Q�！�q�最基本的模型设计、模块设计、分层设计都没做好，难怪年�q�重构、年�q�完成不可能完成的�Q务！�Q�！我确信这�U�重构、这�U�不可能完成的�Q务还会年�q�持�l�下去！�Q�！

�I�竟什么是�W�合SOA风格的系�l�？先看看SOA宗师IBM的一��文章：

http://www.ibm.com/developerworks/cn/architecture/ar-soastyle/

我来�ȝ��一下�?/p>

SOA能达��C��么目的：

1.实现业务与IT的一致性；

2. 创徏更灵�zȝ��反应更敏��L��IT基础设施�Q?/p>

3. ��化集成实玎ͼ�

SOA要怎么做？

从应用程序到��程和服务。消除应用程序，��Y件系�l�创��Zؓ一�l�由业务��程�q�行协调的交互服务。每个服务实��C��业上下文中定义的特定业务目标或功能，业务��程表示必须实现的业务解��x��案。这个讲的比较抽象，我的解读��是服务表示一个最�l�粒度的业务目标或功能，�׃��务流�E�来�~�排�q�些服务�Q�实现更大粒度的业务目标或功能，业务��程也是服务。注意，�q�里隐式的定义了服务的概念，服务是自�ȝ��Q�可替换的，可被多个��程�~�排的，不耦合��程上下文的�Q�是直接面向业务目标或功能的�Q�不是一个公共函数库�Q�服务不是封装了数据和方法的�c�R�?/li>
SOA的服务基于业务资源（对象�Q�定义，不支持操作者的执行上下文，而是支持业务资源�Q�对象）。这里的业务资源是指业务实体。业务实体也是来自业务的。所以，SOA能保证IT与业务的一致性�?/li>

别再说你的应用程序或烟囱遵��@SOA的架构风��|��

�q�途书�?/a> 2012-07-18 21:19 发表评论

软�g架构设计�Q�四�Q?amp;mdash;—软�g架构设计�q�程

Sun, 08 Jul 2012 08:46:00 GMT

3.10 ��定�pȝ��需�?/strong>

��定�pȝ��需求即��定�pȝ��用例。方法以�Ҏ��业务用例实现场景分析��入，分析每个�pȝ��Actor的系�l�用例。每个系�l�用例一定是一个完整的事�g��，注意业务用例和系�l�用例的区别�Q�业务用例是一个完整的业务目标�Q�而系�l�用例是一个完整的事�g��，是业务目标中的一个环节，如客户代表申请开��h��一个完整的�pȝ��用例�Q�但不是一个完整的业务目标�Q�其包括多个��面操作�?/p>

3.11 用例实现分析

�Ҏ��个系�l�用例，识别其可能的实现路径�Q�每个实现�\径就是一个用例实玎ͼ�然后针对每个用例实现�Q�分析�h��Z��互，使用�z�d��囄��制用例实现场景�?/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�发低时延的大数据量查询�Q�Twitter��采用了垂直�~�存�Q�raw�~�存的设计方案�?/p>
3、验证性能设计。抽取典型场景，实现一个prototype来验证性能设计是否满��性能目标�?/p>
在质量属性设计中�Q�如果需要新增模块，则需要修攚w��辑架构�?/p>
有一些约束类需求也是非帔R��要的�Q�不能遗漏分析�?/p>
�l�过�q�一个阶�D�，我们能够得到一个比较完整的逻辑架构�Q�运行架构、开发架构、物理架构、数据架构的输入了。剩下的工作��是�~�档的工作了�?/p>

3.14 架构�~�档

有了上面的工作作为铺垫，�~�档��非常容易了�Q�这个就不细讲了�?/p>

�q�途书�?/a> 2012-07-08 16:46 发表评论

软�g架构设计�Q�三�Q?amp;mdash;—软�g架构设计�q�程

Sun, 08 Jul 2012 07:17:00 GMT

3.4 分析业务用例场景

分别针对上节中业务用例视图中的每一个用例，分析该业务用例在实际工作中是如何做的�Q�一般��用业务活动图来表�q�C��务场景。在�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�如何通过人机交互来完成业务，是业务用例场景的具体化。一般用�z�d��图来表述人机交互��程。这里每个步骤的�_�度是�h与系�l�或�pȝ��与�h的一�ơ交互�?/p>
3.8 领域建模

领域模型是描�q�特定问题域的对象及其相互关�p�R��领域模型对业务对象做了�q�一步的�_�֌�。领域徏模的步骤如下�Q?/p>
1、确定问题域�Q�如CRM中的客户模型比较关键�Q�我们决定对其进行领域徏模，则需要将设计客户业务实体的用例全部识别出来；

2、领域徏模：逐一分析涉及到操作客��h��型的业务用例场景�Q�识别领域对象以及对象之间的关系�Q?/p>
3、验证领域模型：使用序列图作为工��P��Z��领域模型来编排实现各业务场景�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>

�q�途书�?/a> 2012-07-08 15:17 发表评论

软�g架构设计�Q�二�Q?amp;mdash;—软�g架构设计�q�程

Wed, 04 Jul 2012 14:28:00 GMT

三、架构设计的�q�程

本�h�l�历�q�不��项目，一些项目的架构设计负责��力很强，接到�z�M��后，马上一头扎�q�设计，抽象��Z��堆玄玄乎乎的概念�Q�讲得�h晕头转向的，让�h觉得高深莫测�Q�但是，在会议上却被涉众提的一些简单的问题问得很仓促，�I�其�Ҏ��Q�还是漏考虑了涉众的需求，被�h提问而又�~�Z��准备�Q�是不是很多人有�c�M��的经验？�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�劳方）、用戗��我们通常扑ֈ�代表某一�c�d��的涉众群体的代表人：客户代表、劳方代表、用户代表等。访谈的时候直接找代表�q�行�?/p>
3.2 ��定�pȝ��边界

      对于要明��实现某�U�标准的软�g�pȝ��Q�通常��定边界非常�Ҏ��Q�直接按标准圈定的scope分析卛_��Q�比如像SIPServlet容器�Q�是要求遵从JSR168规范的，那么软�g�pȝ��的Scope��是JSR168规定的Scope�Q�但是也有例外，比如客户或者劳�Ҏ��指定要复用一个现有的实现了部分功能的�pȝ��或组�Ӟ��那么Scope��׃��同了。对于没有标准的软�g�pȝ��Q�就需要分别访谈客户代表、承接方代表��定�pȝ��边界。�ؓ什么要访谈承接方代表呢�Q�因为承接方代表往往是劳斚w��|��领导肩负企业战略达成的��命，很有可能对系�l�提出比客户更多的要求。�D个例子，某客户需要一个SIP通信协议栈，以实��C��斚w��话的业务，但是��x��领导认�ؓ�Q�后�l�ICT融合是趋势，我们构徏的系�l�要支持ICT融合应用部��v和运行，支持业务标准JSR168规范�?/p>
3.3 软�g需求收�?/strong>

      软�g需求可分�ؓ二类�Q?/p>
      功能需求（即业务用例）�Q�描�q�Actor�Q�用��h��pȝ��Q�可��Z��软�g�pȝ��做什么事�Q�要�W�合什么业务规则；

      非功能性需求又可分��Z��c�：

      质量属性：质量属性指软�g�pȝ��的品质，可分��行期质量属性与开发期质量属性�?/p>

        �q�行期质量属性包�?/p>

      �Q?�Q�性能�Q�性能是指软�g�pȝ��及时提供相应服务的能力。具体而言�Q�性能包括速度、吞吐量和持�l�高速性这三方面的要求�?br>　　�Q?�Q�安全性：指��Y件系�l�同时兼��֐�合法用户提供服务�Q�又��L��非授权��用功能的能力�?br>　　�Q?�Q�易用性：指��Y件系�l�易于��用的�E�度�?br>　　�Q?�Q�可用性：可用性与易用性不相同。可用性指�pȝ��长时间无故障�q�行的能力�?br>　　�Q?�Q�可伸羃性：指当用户增加�Ӟ��软�g�pȝ��l�持高服务质量的能力�?br>　　�Q?�Q�互操作性：指本软�g�pȝ��与其他系�l�交换数据和�怺�调用服务的难易程度�?br>　　�Q?�Q�可靠性：软�g�pȝ��在一定时间内无故障运行的能力�?br>　　�Q?�Q�健壮性：也称定w��性。是指��Y件系�l�在异常情况仍能够正常运行的能力�?/p>

       开发期质量属性包括：

   �Q?�Q�易理解性：是指�pȝ��设计能被开发�h员理解的难易�E�度�?br>　　�Q?�Q�可扩展性：为适应新需求或者需求变化，��Y件增加功能的能力。有些时候，�U�C��为灵�z�L��?br>　　�Q?�Q�可重用性：重用软�g�pȝ��或其中一部分的能力的难易�E�度�?br>　　�Q?�Q�可��试性：对��Y件测试以证明其满��需求规�U�的难易�E�度。在实际的项目中�Q�主要指�q�行单元��试�{�难易程度�?br>　　�Q?�Q�可�l�护性：修改Bug�Q�增加功能，提高质量属性�?br>　　�Q?�Q�可�U�L��性：��Y件系�l�从一个运行环境�{�U�d��另一个不同的�q�行环境的难易程度�?/p>

      �U�束�Q�规定开发��Y件系�l�时必须遵��@的限制条�Ӟ��如要��Z��什么操作系�l�，要基于什么开发语�a��{�等�?/p>
      对于功能需求，可找�pȝ��的直接��用用户代表，对其�q�行访谈�Q�收集其要基于系�l�做的事情，可按照标准的用例模板�Q�在访谈的过�E�中引导用户代表。之后，�l�制业务用例视图�Q��ƈ针对每个业务用例�Q��用标准的用例模板��功能需求编档，通常叫用例规�U��?/p>
      对于非功能性需求，可找软�g�pȝ��的涉众，依据下面的模板，引导涉众�Q�收集其对相应质量属性的要求�Q?/p>

�ȝ��Q�本阶段需要输��Z��务用例视图，业务用例规约�Q�非功能性需求�?/strong>

待箋。。�?/strong>

�q�途书�?/a> 2012-07-04 22:28 发表评论

软�g架构设计�Q�一�Q?amp;mdash;—软�g架构的概念和表述

Thu, 28 Jun 2012 15:29:00 GMT

做了好几�q�架构设计的事了�Q�一直没有好好的�ȝ��。实在不好，��q��旉��ȝ��一下，写出来，有兴��的朋友可以一��h��讨�?/p>
软�g架构设计的主题狠��q��难，本文打算从架构的概念�Q�架构的表述�Ҏ��Q�架构设计的�q�程三个斚w��来讲一下我的理解�?/p>
一、什么是软�g架构�Q?/strong>

      温昱在《��Y件架构设计》一书中�Q�给了下面的定义�Q?/p>
      �l�合�z�：软�g�pȝ��的架构将�pȝ��描述��组件及�l��g之间的交互�?br>      决策�z�：架构是一�p�d��重要决策的集合，�q�些决策与以下内�Ҏ��养I��软�g的组�l�，构成�pȝ��的结构元素及其接口的选择�Q�这些元素在�怺�协作中明��表现出的行为，�q�些�l�构元素和行为元素进一步组合所构成的更大规模的子系�l�，以及指导�q�一�l�织--包括�q�些元素及其接口、它们的协作和它们的�l�合--架构风格�?/p>
      在我看来�Q�决�{�派的定义更为具体和准确�Q�注意决�{�派用了元素�q�一词而没有用�l��g�Q�组件是有具体含义的�Q�指一个可独立替换的物理单元，而架构需要能够指导涉众，如开发�h员、用戗��部�|��h员等�{�，对开发�h员来�Ԍ��开发过�E�中如何分包、如何将包打包�ؓ�l��g�Q�架构师需不需要提供指导呢�Q�答案是肯定的。因此，如果��架构限定在�l��g和组件的交互上，是不完整的�?/p>
二、架构的表述�Ҏ��
     �q�个现在都有��p��Q�就�?+1视图表述法：逻辑视图�Q�实现视图，�q�程视图�Q�部�|�视图，用例视图�?参见下图RUP 4+1视图�Q?

      用例视图��x��pȝ��的�h、事、物、规则，人是指系�l�的Actor�Q�包括业务主角和业务工�h�Q�事是指�pȝ��用例�Q�物是指业务实体�Q�规则指做事情的前置条�g、后�|�条�Ӟ��做事情过�E�中的规则。下面这个图很精辟：

      用例视图�?+1视图中的+1�Q�它定义需求标准，跟其它视图描�q�系�l�某一斚w��的结构有很大的不同�?
      逻辑视图��x��pȝ��的逻辑功能模块和领域模型，不仅包括用户可见的功能模块，�q�包括实现用户功能而必��L��供的“辅助功能模块”；它们可能是逻辑层、功能模块、类�{��?
      实现视图��x��E�序包，不仅包括要编写的源程序，�q�包括可以直接��用的�W�三方SDK和现成框架、类库，以及开发的�pȝ��运行于其上的系�l��Y件或中间件。开发架构和逻辑架构之间可能存在一定的映射关系�Q�比如逻辑架构中的逻辑层一般会映射到实现架构中的多个程序包�Q�再比如实现架构中的源码文�g可以包含逻辑架构中的一到多个类�Q�在C++里一个源码文件可以包含多个类�Q�即使在Java里一个源码文件也可以同时包含一个类和几个内部类�Q��?
      �q�程视图��x��q�程、线�E�、对象等�q�行时概念，以及相关的�ƈ发、同步、通信�{�问题�?
      �q�程视图和实现视囄��关系�Q�实现视图一般偏重程序包在编译时期的静态依赖关�p�，而这些程序运行�v来之后会表现为对象、线�E�、进�E�，�q�程视图比较��x��的是�q�些�q�行时单元的交互问题�?
      物理视图��x��“目标程序及其依赖的�q�行库和�pȝ��软�g”最�l�如何安装或部��v到物理机器，以及如何部��v机器和网�l�来配合软�g�pȝ��的可靠性、可伸羃性等要求。物理架构和�q�行架构的关�p�：�q�行架构特别��x��目标�E�序的动态执行情况，而物理架构重视目标程序的静态位�|�问题；物理架构�q�要考虑软�g�pȝ��和包括硬件在内的整个IT�pȝ��之间是如何相互媄响的�?
      上面几个视图是最典型的视图，不管你是通信中间�Ӟ��q�是依赖于数据库的企业应用都需要的。对于依赖数据库的企业应用，通常�q�需�?strong>数据视图�Q�数据视�?/strong>��x��对象如何存储�Q�如数据库表�{?strong>�?/strong>
       4+1视图不仅仅是软�g架构的表�q�方法，它们各自从不同的视角��d��现架构，因此�Q�还是一�U�比较好的思维方式�Q�引导我们从不同的视角去思考，从而做出比较系�l�的架构设计�?/p>

�q�途书�?/a> 2012-06-28 23:29 发表评论

Sun, 24 Jun 2012 08:29:00 GMT

某司CRM产品�Q�认��业务��程的业务才是订单。按照这�U�理解，退货，换货是订单，而充��g��是订单�?/p>
�I�竟什么是订单?

订单作�ؓ一个业务Actor皆可感知的重要业务实体，其是��q��IT�pȝ��而存在的�Q�IT�pȝ��所做的仅是��其在��Y件系�l�中以对象的形式表现出来�Q�不能依据系�l�实玎ͼ�改变订单的定义。要正确的给订单下定义，��d��掉IT�pȝ��Q�从业务的角度给出定义�?/p>
企业一般会有售前，售后�Q�销售，服务�{�部门，而订单是产生在销售活动中的，表示客户对企业��品或服务的一�ơ订购。依此理解，退换货是服务，不是订单�Q�而充值是订单。走不走��程�Q�仅仅是订单实施的方式�?/p>
�q�个案例告诉我们�Q�系�l�的业务模型�Q�要从业务的视角来徏�Q�IT�pȝ��是将业务模型用��Y件概忉|��表述�Q�不能改变业务概��c�?/p>

�q�途书�?/a> 2012-06-24 16:29 发表评论

Top Ten Use Case Mistakes

Fri, 23 Mar 2012 20:19:00 GMT
http://drdobbs.com/184414701
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

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.
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

Use case text that contains violations of five of the top 10 rules.
[back to text]
Figure 3. The 1040EZ Approach to Use Cases

The use case text with the mistakes corrected.

�q�途书�?/a> 2012-03-24 04:19 发表评论

Driving Design: The Problem Domain

Fri, 23 Mar 2012 20:17:00 GMT
http://drdobbs.com/architecture-and-design/184414689
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
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.
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
This class diagram violates the third, fifth, sixth, eighth and ninth rule from our top 10 list of domain modeling mistakes.
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
The rule violations found in Figure 2 are corrected here.
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.

�q�途书�?/a> 2012-03-24 04:17 发表评论

Driving Design with Use Cases

Fri, 23 Mar 2012 20:14:00 GMT

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

�q�途书�?/a> 2012-03-24 04:14 发表评论

Robustness Diagram - 从需求分析到架构设计

Fri, 23 Mar 2012 20:10:00 GMT
     摘要:   阅读全文

�q�途书�?/a> 2012-03-24 04:10 发表评论

Sun, 11 Mar 2012 11:30:00 GMT

对一些需求变化多��L��产品而言�Q�做好可变性设计是非常重要的。国外做得好的有Siebel�Q�国内有金蝶的BOS�Q�实际上金蝶的BOS很多理念跟Siebel是相似的�Q�呵��c��。。他们都是采用MDD的方式来解决可变性问题的�?/p>
�q�里的难点在于如何抽象出一套稳定的元模型，能描�q�各�U�各��L��变化�Q�以辑ֈ�通过配置卛_��搞定需求变更的目的�?/p>
�q�里着重讲一下金蝶BOS的元模型�Q�所谓元模型�Q�是模型的模型�?/p>
在数据层�Q�有Table�Q�Table对应到数据库表，直接三种Table之间的关�p�，什么交叉表、扩展表之类的，基本与��^常大家设计表的范式对应，不多��_��

在业务逻辑层，有实体，实体表示�pȝ��的领域实体对象，一个实体对应到一个Table�Q�实体的属性对应到Table的field或其扩展表的Field�Q�实体与实体之间有关�p�，关系分�ؓOne2One�Q�One2Many�Q�Many2One�Q�Many2Many。还可以对实体的属性定义计��公式，�U�束�?font color="#ff0000">但缺乏实体��别的�U�束。我认�ؓ金蝶可以增加�q�一个小�Ҏ��：�Q�。实体可�l�承另一个实体，以获得另一个实体的定义�?/font>

可以为实体定义方法，�Ҏ��映射��C��个规则。也��是说调用这个方法的时候实际执行的是这个规则；

可以为实体定义查询方案、过滤方案、排序方案，主要是以OO的方式做实体查询�Q�对外暴露OO化的用户接口�Q�对内生成SQL用；

可以为实体定义事�Ӟ��Function和Facade可监听事�Ӟ��事�g由Function触发�?/p>
金蝶对Function的解释是“业务功能是对运行系�l�的Entity对象、UI对象及其�Ҏ��的一定封装，供其它模块或二次开发��用”，比如上文提到的事�Ӟ��x��由Function触发的，但不知�ؓ什么还要指定事件的�Ҏ��Q�Function是事件的生��者，事�g的方法表�C�Z��件的消费者（监听者）�Q�这样做不是��D��生��者与消费者耦合了吗�Q�？那还要事件干什么，不知道有没有朋友能解�{�这个问题？�Q�Function�q�可以绑定到一个UI的Action�Q�意味着当该UI对象的Action触发�Ӟ��会执行这个Function。对UI Action的绑定是可选的�?/p>
Facade表示领域Service对象�Q�相比实体，其仅仅有�Ҏ��Q�没有属性�?/p>
UI对象表示一个界面对象，比如订单创徏对象�Q�可以对其指定Layout�Q�UI对象支持�l�定实体、Query对象。UI对象也有事�g、Action和状态，事�g和Action应该可以�l�定到Function和Facade�Q�State表示界面对象的状态，比如界面通常有编辑状态、查看状态等�{�。UI对象�q�有个父对象�Q�还没怎么弄清楚UI对象与UI对象之间的关�p�，没有看到描述�Q�需要进一步研�IӞ��感觉BOS对UI层的抽象略显��单，通常UI层是最复杂的，有字�D�联动，子页面联动等�{�，没见到BOS怎么来搞定这�U�联动场景�?/p>

查询表示对对象的查询�Q�需要绑定一个对象树�Q�可定义查询�Ҏ��、过滤方案、排序方案，生成SQL用；

�q�有其它的一些非主要元模型�?/p>
通过UI Object、Entity/Function/Facade、和Table�Q�可支持描述界面、领域对�?服务、数据库表以及它们之间的�l�定关系�Q�如果对象模型有变更、或者业务逻辑有变��_��会导致这三层的对象的变化�Q�而变化可��Z��q�三层的元模型描�q�ͼ�实现配置卛_��用�?/p>

�q�途书�?/a> 2012-03-11 19:30 发表评论

Sun, 11 Mar 2012 10:19:00 GMT

昨天�Q�有人问我对Spring的理解，�ȝ��一下：

Spring现在已经覆盖�pȝ��各个层次�Q�在web层，有Spring Web、Spring Webflow�Q�在业务逻辑层，有Spring Core�Q�在数据持久层，Spring整合了Ibatis�Q�SQL Mapping�Q�、Hibernate�Q�ORM�Q�、NOSQL�Q�在集成层，Spring有Spring Integration�Q�还有针对特定场景的解决�Ҏ��Q�如Spring batch、Spring Message、Spring Security、Spring Social�{�等�?/p>
Spring Core是一个IOC容器�Q�负责对象的生命周期��理�Q�正因�ؓ其负责了对象的生命周期管理，Spring可以通过Proxy和AOP�{�技术在对象创徏和调用的时候玩一把魔术，如：动态�ؓ对象的调用植入一些代码，使得开发�h员可以把业务逻辑无关的调用系�l�服务的逻辑切面化，实现声明式配�|�。另外，Spring�q�负责了对象的组装，使得面向接口的编�E�更为简单，省去很多Factory逻辑�?/p>
其它�Ҏ��都可以说是基于Spring Core的，面向特定应用场景的解��x��案，不多说�?/p>

�q�途书�?/a> 2012-03-11 18:19 发表评论

面向领域的业务��^台设计（二）

Sun, 26 Feb 2012 09:12:00 GMT

如何解决上文提到的鉴定标准中的问题呢�Q�我认�ؓ�{�案��是MDD�?/p>
用一个实际的例子来表�q�C��下思�\�Q?/p>
在CRM�pȝ��有个订单处理模块�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��一��L��Q�处理工单的界面也��L��一��L��Q�展现订单的界面也��L��一��L��。因此，我们可针�Ҏ��定的对象的某�U�需要展现的状态，提供合适的展示构�g�Q�WEB TAG�Q�来展示它�?/p>
在持久层�Q�因为对象��L��持久化到一张表当中的，因此�Q�可用一些ORM的框架来持久化对象，而不是开发�h员针�Ҏ��个场景去写SQL�Q�复杂的兌��查询可以使用�c�HQL�?/p>
各对象之间的兌��操作通过事�g驱动�?/p>
举一个订单创建的例子�Q?/p>
1、开发做的工作：

    1�Q��用元数据定义订单的数据结构，包含持久化元数据、基本属性元数据、字典元数据�Q?/p>
    2�Q�定义订单状态机�Q�以及状态变�q�的规则�Q?/p>
    3�Q�徏模订单处理流�E�；

    4�Q�定义订单请求处理规则流�Q��ƈ发布��Z��个受理订单请求的服务�Q?/p>
    5�Q�开发订单创建界面，使用订单WEB构�g来展�C��单对象；

    6�Q�定义事�Ӟ��以及事�g的监听服务；

2、系�l�执行流�E�：

    1�Q�营业员打开订单创徏界面�Q�系�l�获取订单对象的元数据，生成订单创徏��面�Q?/p>
    2�Q�营业员点击订单创徏界面的提交按钮，调用受理订单��h��的服务；规则��执行，如果规则校验错误�Q�则�q�回错误�Q�如果成功，则创��单，�q�回成功�Q?/p>
    3�Q�因创徏订单�Q�导致订单的状态变为创建状态，触发订单创徏事�g�Q?/p>
    4�Q�订单创建的监听服务��程服务接收��C��Ӟ��触发订单处理��程的创建；

    5�Q�流�E�执行的�q�程中编排第三方�pȝ��服务�Q�流�E�执行结束后�Q�触发订单流�E�结束事�Ӟ��程�l�束事�g的监听服务订单管理接收到事�g�Q�触发状态机变迁�Q�订单状态变为完成�?/p>
上述开发做的工作全部可通过配置完成。后�l�如果增删字�D�，修改元数据即可，要增删改业务规则�Q�调整业务规则即可，要调整实体状态，修改实体状态机卛_��?/p>
业务�q�_��要致力于对状态机、业务流�E�、SEP、元数据、领域化的WEB构�g的实玎ͼ��q�将其有机整合�?/p>

写的比较乱，�q�几天再整理一下。。�?/p>

�q�途书�?/a> 2012-02-26 17:12 发表评论

Sun, 26 Feb 2012 07:04:00 GMT

毕业后，做了很多�q�的中间�Ӟ��有工作流�Q�有数据持久层框�Ӟ��q�有个类似tomcat的server�{�，一直在思考，一个最适合业务的��^台应该是什么样子的。因一直没有业务经验，因此�Q�尽��有一些想法，但是也不知道�q�些��x��靠不靠谱�Q�最�q�一�q�参与了一个CRM��目的设计，�U�攒了一些业务经验，心中的想法逐渐清晰了�v来，也有了一些底气，写下来跟大家交流探讨�?/p>
��如同变化多端的八卦卦象是由乾、兑、离�{?个基本卦象组成，万事万物是由数种原子构成�Q��Ş态各异的高楼大厦是由砖头和砂��砌成，应用也有构成其的“元”，��x��件�?/p>
业务应用是分层的�Q�典型的分层是展现层、流�E�层、服务层、数据持久层�Q�每一层次的关注点都不同，构�g也不相同�Q�比如一个业务逻辑层的构�g输出的数据，会通过展现层的构�g来展现在界面上。且各层之间的诏通黏合（如MVC中的Controller层就是黏合逻辑�Q�，通常要耗费比较多的开发精力，一个好的业务��^収ͼ�除了在各层次分别提供可复用的构�g�Q�需要能够减��各层黏合的工作量�?/p>
面向特定领域的业务��^台的易用度与光��用面是鱼和熊掌的关�p�，针对特定领域�Q�要��易用，则��^台能力就要越面向特定领域�Q�则��不通用�Q�导致适用面越�H�。因此，一个好的��^収ͼ�要注意分层，比如分成通用的构件和领域化的构�g。业务用户可按需使用。同�Ӟ��q�需要在各层�ơ开攑֮�制能力，供业务用户在各层提供领域构�g�?/p>
现在的��品交付都是解��x��案��的交付，解决�Ҏ��由多个系�l�或子系�l�构成，一个部门，一个项目组通常只是提供解决�Ҏ��中的一个部�Ӟ��负责端到端的业务功能中的一个环境，因此�Q�需要支持构件的�l�装�Q�以形成更大�_�度的构�Ӟ��支撑软�g复用与集成�?/p>
开发一个子�pȝ��_�度的构仉��常是一件很复杂的事情，如CRM�Q�需求琐��、变化频�J�、不同客戯��求不��相同，如果�~�Z��一个好的支撑��^収ͼ�人力成本会很高，TTM也会很长�Q�因此，一个好的业务��^収ͼ�也需要能够支撑快速的构�g开发、定制�?/p>
解决构�g的组装和集成�Q�已�l�有比较成熟的技术了�Q�如ESB、SCA�{�，IBM、Oracle�{�大厂商都有提供集成化的开发环境和执行环境。但如何支撑构�g的开发这块，各大厂商也有支撑�Q�比如在展现层，Oracle有ADF�Q�在��程层，IBM和Oracle都提供了BPM�Q�在service层，IBM和Oracle提供了规则引擎，VMWare的Spring�Q�在持久层，Oracle提供了Toplink�Q�还有就JBOSS大名鼎鼎的Hibernate。所有前面提到的�q�些都是业务无关的技术部�Ӟ��且各层之间的靠业务开发�h员自己来黏合�Q�还是不够领域化。因此，一个业务��^収ͼ�仅仅去重复制造IBM、Oracle造过的轮子，是完全没有竞争力的（�q�里不算成本�Q�。面向特定领域，评判一个业务��^台是否优�U�的标准是�Q?/p>
1、是否提供了丰富的领域构�Ӟ��

2、是否能够节省业务开发�h员黏合各层的工作量？

3、提供了什么样的机制来应对需求变化？比如有的客户要求多加个字�D�c��加个校验，有的客户要求��个字段、少个校验等�{��?/p>
待箋。。�?/p>

�q�途书�?/a> 2012-02-26 15:04 发表评论

Sat, 25 Feb 2012 16:51:00 GMT

�q�来参与了一个电信CRM��目的设计，相比其他电信应用来讲�Q�CRM最接近用户�Q�因此，需求琐��，变化频繁。需要有一个适应CRM业务的领域化IDE来支撑业务开发�?/p>
做事情需要有�Ҏ��Q�方法可以参考业界一些好的实��c��本文主要是��x�ȝ��一些好的设计IDE的实践供朋友们借鉴�?/p>
我们借IBM的BPM Suite来分析IDE的设计方法�?/p>
IBM BPM Suite主要用于业务��程的管理。IBM把业务流�E�的生命周期划分为流�E�徏模、流�E�开发、流�E�部�|�Ӏ�流�E�监�?个环节，针对�q?个环境，定义了相应的角色执行相应环节的工作。然后再针对指定的角�Ԍ��提供了专门的workspace来支撑其工作�Q�实��C��对其不关心的数据和配�|�的��装和隐藏�?/p>
�q�种�Ҏ��论其实是通用的，对CRM应用来讲�Q�其开发生命周期也可分为几个阶�D�，每个阶段的参与Actor需要��用的信息、不需要了解的信息都不同。同�Ӟ��一个现代SOA应用在技术上通常会分层，典型的分层是UI、流�E�、Services、Entities。需要根据Actor�Q�仔�l�分析在每个分层上的开发用例，从而构建出最适合各种Actor的IDE�?br />
本�h最�q�在研究BPEL和BPMN�Q�希望能和对此有研究的朋友探讨一些技术问题，联系QQ�Q?8425726�Q�盼指教�?br />

�q�途书�?/a> 2012-02-26 00:51 发表评论

Sun, 11 Oct 2009 12:21:00 GMT
     摘要:   阅读全文

�q�途书�?/a> 2009-10-11 20:21 发表评论

工作��合单的实现

Mon, 06 Jul 2009 15:22:00 GMT
     摘要:   阅读全文

�q�途书�?/a> 2009-07-06 23:22 发表评论

Sat, 30 May 2009 02:48:00 GMT
     摘要: JBOSS的JBPM负责人的一��文�?nbsp; 阅读全文

�q�途书�?/a> 2009-05-30 10:48 发表评论

Thu, 01 Jan 2009 01:59:00 GMT
http://www.workflowpatterns.com/patterns/resource/resource_modelling.php
http://www.workflowpatterns.com/patterns/resource/workflow_structure.php
http://www.workflowpatterns.com/patterns/resource/work_distribution.php

workflowpatterns�ȝ��了工作流的许多模式，机理是petri�|�那一套。oracle的auqualogic实现机制��p��着三篇文章讲得差不多�?br /> 有自己实现工作流引擎的朋友可以借鉴一下，本�h�Ҏ��也小有研�IӞ��Ƣ迎交流�?br />

�q�途书�?/a> 2009-01-01 09:59 发表评论

快速构建面向服务的应用-2

Wed, 19 Nov 2008 14:55:00 GMT

�ȝ��一下，个�h认�ؓ企业应用的核心组成要素是“数据 + 服务”�Q?/span> 而服务又分�ؓ原子服务�Q�聚合服务，��程服务。权限也是一�U�数据，�?#8220;权限服务”消费。后面暂不考虑权限处理。信令流因�ؓ用得��，很多人可能都不知道是什么东西，�q�里也不考虑�Q�如果遇��C��记得使用��程技术把信号的处理也��程化就可以了，可参�?/span>apache�?/span>SCXML�Q�虽然号�U�是个状态机引擎�Q�但是请君用你的慧眼观察一下它�?/span>schema�Q�显然是一个活动图�?/span>

接下来的推导分�ؓ两个阶段�Q�第一阶段先推导支撑技术，�W�二阶段再推��g��什么样的开发方式将�q�些支撑技术串��h��Q�达到快速开发的目的�?/span>

下表中列��Z��对上面的核心�l�成要素�Q�数�?/span>+服务�Q�的一些支撑技术：

要素

支撑技�?/span>

考虑

数据实体

Java�Q?/span>sdo�Q?/span>c++�{�等

原子服务

Java�Q?/span>c++�Q?/span>c�Q�脚本等�{?/span>

没什么可说的�Q�码肯定是要�~�的

聚合服务

SCA

�?/span>sca来将原子服务装配成聚合服务。如果想要��用什么数据�{换啊�Q�接口映��啊�Q�安全控制啊之类的特性的话也可以引进ESB�Q�作�?/span>SCA的一�U?/span>container�?/span>

操作��程

实现一�?/span>SCA中的container�Q�接受操作流�E�的描述文�g的作为执行文�?/span>

View process

�?/span>web应用下，采用一�U?/span>webflow的实玎ͼ�swing下就自己写把�?/span>

Business process

WFA�c�L��E�，EOS or OBE�c�M��的工作流引擎�Q�可直接��?/span>EOS或�?/span>OBE提供�?/span>API作�ؓ一个原子组�?/span>

Orchestration Process

EAI�c�L��E�，�?/span>ODE�Q�一�?/span>bpel引擎�Q�也作�ؓSCA的一�?/span>container�Q?/span>BPEL作�ؓ一�U�组件实现方�?/span>

下面在列一些辅助支撑技术，�q�些技术是��Z��让企业应用这些大厦能够构建的更快�Q�毕竟盖房子�Q�有了水泥和砖是不够的，�q�要有扁担，��箕�{�等�?/span>

技�?/span>

作用

元数据技�?/span>

利用元数据描�q�数据实体，以及�Ҏ��据实体、实体属性的�U�束、权限等信息�Q�可以基�?/span>RBAC的权限系�l�设计思�\�Q�将用户�l�织机构与权限关联�v来，实现自动生成��面�Ӟ��对特定用��L��权限控制�Q�等�{�其它的东东�?/span>

表单生成技�?/span>

�Ҏ��元数据生成表单，支持可视化的定制表单布局�{�，支持生成jsp�{�，如果需要多�U�展玎ͼ�可以生成多种特定的展现实玎ͼ��?/span>swing界面�{?/span>

囑�Ş化徏模技�?/span>

可视化的建模view process�Q?/span>Orchestration process�Q?/span>business process�Q?/span>operation process�{?/span>

囑�Ş化组件装配技�?/span>

可视化的��组件装配成大粒度组件等

代码生成技�?/span>

�Ҏ��元数据生成数据实体�?/span>DAO代码�{?/span>

�q�里�q�个SCE大致包括一些什么东西就清楚了，下面用一个序列图来表�C�用户基�?/span>SCE的一�U�自��向下的开发方式。当然也应该支持自下而上�?/span>

�q�途书�?/a> 2008-11-19 22:55 发表评论

快速构建面向服务的应用-1

Fri, 07 Nov 2008 15:50:00 GMT
     摘要: 快速构建面向服务的应用  阅读全文

�q�途书�?/a> 2008-11-07 23:50 发表评论

Thu, 04 May 2006 16:17:00 GMT
     摘要: �? �? ...  阅读全文

�q�途书�?/a> 2006-05-05 00:17 发表评论

要素	支撑技�?/span>	考虑
数据实体	Java�Q?/span>sdo�Q?/span>c++�{�等
原子服务	Java�Q?/span>c++�Q?/span>c�Q�脚本等�{?/span>	没什么可说的�Q�码肯定是要�~�的
聚合服务	SCA	�?/span>sca来将原子服务装配成聚合服务。如果想要��用什么数据�{换啊�Q�接口映��啊�Q�安全控制啊之类的特性的话也可以引进ESB�Q�作�?/span>SCA的一�U?/span>container�?/span>
操作��程	实现一�?/span>SCA中的container�Q�接受操作流�E�的描述文�g的作为执行文�?/span>
View process	�?/span>web应用下，采用一�U?/span>webflow的实玎ͼ�swing下就自己写把�?/span>
Business process	WFA�c�L��E�，EOS or OBE�c�M��的工作流引擎�Q�可直接��?/span>EOS或�?/span>OBE提供�?/span>API作�ؓ一个原子组�?/span>
Orchestration Process	EAI�c�L��E�，�?/span>ODE�Q�一�?/span>bpel引擎�Q�也作�ؓSCA的一�?/span>container�Q?/span>BPEL作�ؓ一�U�组件实现方�?/span>

技�?/span>	作用
元数据技�?/span>	利用元数据描�q�数据实体，以及�Ҏ��据实体、实体属性的�U�束、权限等信息�Q�可以基�?/span>RBAC的权限系�l�设计思�\�Q�将用户�l�织机构与权限关联�v来，实现自动生成��面�Ӟ��对特定用��L��权限控制�Q�等�{�其它的东东�?/span>
表单生成技�?/span>	�Ҏ��元数据生成表单，支持可视化的定制表单布局�{�，支持生成jsp�{�，如果需要多�U�展玎ͼ�可以生成多种特定的展现实玎ͼ��?/span>swing界面�{?/span>
囑�Ş化徏模技�?/span>	可视化的建模view process�Q?/span>Orchestration process�Q?/span>business process�Q?/span>operation process�{?/span>
囑�Ş化组件装配技�?/span>	可视化的��组件装配成大粒度组件等
代码生成技�?/span>	�Ҏ��元数据生成数据实体�?/span>DAO代码�{?/span>

亚洲成a人片7777,亚洲av综合av一区二区三区,亚洲av无码成人影院一区

软�g架构设计�Q�四�Q?amp;mdash;—软�g架构设计�q�程

软�g架构设计�Q�三�Q?amp;mdash;—软�g架构设计�q�程

软�g架构设计�Q�二�Q?amp;mdash;—软�g架构设计�q�程

软�g架构设计�Q�一�Q?amp;mdash;—软�g架构的概念和表述

Top Ten Use Case Mistakes

Driving Design: The Problem Domain

Driving Design with Use Cases

Robustness Diagram - 从需求分析到架构设计

面向领域的业务��^台设计（二）

工作���合单的实现

快速构建面向服务的应用-2

快速构建面向服务的应用-1

工作��合单的实现