软件工程概论教学资料：crc 新.docVIP

面向对象的分析过程可分为两个阶段，即论域分析阶段和应用分析阶段。 论域分析 论域分析是软件开发的基本组成部分，目的是使开发人员了解空间的组成，建立大致的系统实现环境。论域分析给出一组抽象，从高层表示论域知识，常常超出当前应用的范围，作为特定系统需求开发的参考。 论域分析实际上是一种学习，软件开发人员在这个阶段尽可以地理解当前系统与应用有关的知识。应放开思维，放宽考虑的领域，尽可能标识与应用有关的概念。论域分析的边界可能很模糊，有了广泛的论域知识，涉及到具体的应用时，就可以更快地进入情况，掌握应用的核心知识。而且，在用户改变对目标系统的需求时，广泛的分析可以帮助我们预测出目标系统在哪些方面会发生哪些变化。 通常进行小组分析，小组成员可以包括领域专家和分析员等。在分析过程中标识出系统的基本概念：对象、类、方法、关系等。识别论域的特征，把这些概念集成到论域的模型中。论域的模型中必须包含概念之间的关系，还有关于每个单独概念的全部信息。这里信息起一种胶合作用，把标识出的相关概念并入论域综合视图中去。 应用分析 应用分析是依据在论域分析时建立起来的问题论域模型，并把问题论域用于当前特定的应用之中。 首先，通过收集到的用户信息来对论域进行取舍，把用户需求作为限制来使用，缩减论域的信息量。因此，论域分析的视野大小直接影响到应用分析保留的信息量。 一般来说，论域分析阶段产生的模型并不需要用任何基于计算机系统的程序设计语言来表示，而应用分析阶段产生的影响条件则通过某种计算机系统的程序设计语言来表示。 模型识别的要求可以针对一个应用，也可以针对多个应用。通常我们着重考虑两个方面，即应用视图和类视图。在类视图中，必须对每个类的规格说明和操作进行详细化，并表示出类之间的相互作用。 过去系统分析和系统设计都是分离的，正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样，这样割裂的结果导致，需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化。 　　DDD）则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。 DDD革命性在于：领域模型准确反映了业务语言，而传统J2EE或Spring+Hibernate等事务性编程模型只关心数据，这些数据对象除了简单setter/getter方法外，没有任何业务方法，被比喻成失血模型，那么领域模型这种带有业务方法的充血模型到底好在哪里？DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。重点不同导致编程世界观不同。 　　CRC模型被开发人员和用户成功地用于理解整个系统开发周期中面向对象的应用，CRC模型是一种惊人的用于领域建模的有效工具，也就是说为领域中的基本概念进行建模。CRC建模是一个迭代的过程：发现类、发现职责和定义协作者。 　　一个类代表一组相似对象的集合，一个对象是与所讨论的系统之中相关的一个人、地址、物品、时间或概念。类的名字出现在横跨CRC卡片顶端的区域，并且通常是单个名词或名词词组，如顾客、图书和资源等。使用单个名词是因为每个类都代表单个对象的泛化形式，所以类名用单数而不是复数，类的名称还应该简要直观。 　　发现类，从本质上讲是一项分析工作，因为它为应用程序确定构件。使用以下策略来发现潜在的类：（1）参与者是潜在的类；（2）确定客户；（3）跟踪资金流；（4）领域的术语概念是候选的类；（5）领域中的关键事件是潜在的类；（6）主要用户界面元素等。 　　类的职责是类知道的或要完成的事情。例如，顾客有名字、地址和电话号码，这是顾客知道的东西。顾客要借书和还书，这些是顾客要完成的事情。一个类知道和要完成的事情构成了类的职责，重要的一点是，类能够改变它所知道的事情的值，但类不能改变其他类所知道的事情的值。换句话说，类只能更新它们自己的属性，而不能更新其他类。 　　发现职责是需求分析的任务，因为它定义某个类是什么，而不管它是如何实现的。对象范型基于以类的形式表示数据（类知道的事情）和功能（类要完成的事情）的组合，这也正是为什么CRC建模特别适合面向对象开发的原因。确定职责的一种方法是，应该问自己某个类需要做什么，即某个类必须执行那些功能。另一种方法是问自己必须存储类的一些什么消息。 　　有时一个类要实现某一职责，但却没有足够的信息去完成该职责，就必须依靠与其他类协作来完成工作。协作通过以下两种形式之一完成：即对信息的请求或对完成某项工作的请求。仅当类A为类B完成某些事情的时候，类A才显示为类B的协作者。这里需要理解的一个重要概念是