dmh2002's Blog专注于 ActionScript 3.0 在各应用领域的研究。

这是来自InsideRIA的一篇文章，由RIAMeeting翻译，原文地址是：

http://www.insideria.com/2009/06/ria-architecture-why-it-matter.html

这篇文章主要是想纠正一下部分人对好的应用程序架构不是很重视的一种现象。

        软件设计因为引入面向对象思想而逐渐变得丰富起来。“一切皆为对象”的精义，使得程序世界所要处理的逻辑简化，开发者可以用一组对象以及这些对象之间的关系将软件系统形象地表示出来。而从对象的定义，进而到模块，到组件的定义，利用面向对象思想的封装、继承、多态的思想，使得软件系统开发可以向搭建房屋那样

        为了让我们的需求更完美，这一篇所要做的工作也是必不可少的。这一篇将要讨论到的内容包括：用例补充规约，系统原型，以及需求规格说明书
        终于到了快结束的时候了，这将是用例分析系列的最后一篇，结果是得到需求规格说明书，以结束需求分析的过程。经过前面七篇的工作，我们从最初的业务用例获取入手，获得了业务用例模型，这是我们的业务范围；经过分析得到了业务场景，这是我们的业务蓝图；经过规划，得出用例实现视图，这是我们的系统范围；经过再次分析，得到了用例实现以及领域模型，包括用例规约，业务规则和业务数据，这是我们的概念模型。仅从需求所需的必要元素来说，我们基本上已经完成了需求分析的工作。诚如上一篇结尾所说，为了让我们的需求更完美，这一篇所要做的工作也是必不可少的。这一篇将要讨论到的内容包括：用例补充规约，系统原型，以及需求规格说明书 
...

       上一篇我们图形化建模的部分基本上完成了，得到了业务用例模型， 这帮助我们获得了功能性需求。得到了业务场景和用例场景，这帮助我们获得了面对业务的执行过程描述和概念（逻辑）模型，让我们知道业务将如何的运作。得到了用例实现以及领域模型，这帮助我们得知哪些业务用例将在系统中实现，对应这些用例，哪些业务实体将会被包括进来，以及它们如何帮助业务实现。上一篇我们也留下了悬念，对于业务执行过程来说，除了以上的成果，我们还需要知道业务规则，以及业务实例的属性。即我们要如何做以及做什么。这一篇就来讨论这些内容。
...

        上一篇确定了业务用例，以及业务场景。该场景只描述了业务框架，接下来要对业务用例进行场景分析。用例场景分析要用到三种视图，业务用例实现视图、业务用例场景、业务实体模型（领域模型），每个业务用例还应当写一份用例文档，也称为用例规约（UseCase Specification）。若有非功能性需求，例如性能要求，吞吐量要求等，还应当写一份补充用例规约。

        上一篇说到我们经过初步的业务分析，得到了用户、业务用例以及业务场景模型。这三项工作成果形成了基本的需求框架，并圈定了业务范围。这时应当做一份基线。 
...

       用户、业务用例以及业务场景。这三项工作成果已经形成了基本的需求框架，并圈定了业务范围。就笔者的工作习惯而言，在得到这三个成果后，就会暂停调研，而通过评审会，研讨会等形式充分论证这些成果的正确性和完备性。求得业务专家，用户代表，开发方，项目经理等各方的一致认可，将其作为第一份基线。 

       很久没有动笔了，这期间承蒙许多朋友的喜欢和鼓励，再不写点东西就对不住这些朋友了。
...

        使用OO方法建立商业模型必须先定义涉众。商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。无论OO也好，UML也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了。
...

        在了解了系统目标以后，系统分析员最先要做的事情不是去了解业务的细节，而是去发现与这个目标相关的人和物。英文把这种人和物称为Stakeholder，在Rose中，这类模型的类型被定义为Business Actor 。有的资料翻译为干系人，笔者则更喜欢涉众这种翻译方法。这就谈到了业务建模的第一步：发现和定义涉众。

        从这一篇开始，笔者将借助一个虚拟的实例来阐述获取用例的方法，以及如何判断用例获取是否完备，粒度选择是否合适。事实上，在做这些工作时，我们正在进行需求分析的第一个阶段，即业务建模阶段。借助这个例子，笔者同样会阐述业务建模到底应该做什么，做到什么地步才能说明业务需求已经完整，可以称为一份完整的需求规格说明书了。
...

        在正式讨论如何获取用例之前，笔者觉得有两个问题还是先解释清楚为好，这对正确获取用例有很大帮助。这两个问题也是初学者最为困惑，也是最难掌握的。一个是各种用例类型之间的区别和用法，另一个是用例的粒度。
        在正式讨论如何获取用例之前，笔者觉得有两个问题还是先解释清楚为好，这对正确获取用例有很大帮助。这两个问题也是初学者最为困惑，也是最难掌握的。一个是各种用例类型之间的区别和用法，另一个是用例的粒度。
...

        我发现，在OO和UML几乎一统天下的今天，仍有很多系统分析员对OO和UML一知半解，甚至包括很多已经使用了很久UML的系统分析员。

        于是打算写一个系列文章，将多年来的工作经验做一个总结。对初学者起个启蒙作用，也希望抛砖引喻，与各路大虾共同探讨，共同提高。

        这个系列文章将以我对OO和系统分析的理解为主，从UML基础开始，阐述面向对象的需求分析方法，过程，并以RUP为例，阐述如何将OO过程与软件过程有机结合在一起，做一个真正OO应用。 
...