软件开发之类、责任、协作者建模

       郑州软件公司认为一旦系统的基本使用场景确定后，则要开始标识候选类并指明它们的责任和协作，类一责任一协作者（Class－responsibilitycollaborator，CRC）建模提供了一种简单的标识和组织与系统或产品需求相关的类的手段。CRC建模的描述如下：

       CRC模型实际上是一组表示类的标准的索引卡片的集合。卡片被分成三个部分，在卡片的顶部为类的名字，在卡片体的左边列出类的责任，在右边列出协作者。

       实际上，CRC模型可以使用真实的或虚拟的索引卡片，其目的是开发一个有组织的类的表示法。责任是和类相关的属性和操作，简单地说，责任是“类知道或做的任何事情”。协作者是为某类提供完成责任所需要的信息的类，通常，协作蕴涵着对信息的请求或对某种动作的请求。

       1）类
 

       总的来说，对象以一系列不同的形式展示出来：外部实体、事物、发生的事情或事件、角色、组织单位、位置或结构。在软件问题的语境内标识这些对象的一种技术是对系统的过程叙述进行语法分析，将所有名词变成潜在的对象，然而，并非每个潜在对象都会成为最终对象。定义6条选择特征：保留的信息、需要的服务、多个属性、公共属性、公共操作以及基本的需求，只有满足所有这6条选择特征的潜在对象，才被考虑包含在CRC模型中。

       Firesmith扩展了上述的类的分类法，只有满足所有这6条选择特征的潜在对象，才被考虑包含在CRC模型中，分类如下：

       （1）设备类。模拟外部实体，如传感器、发动机和键盘等。

       （2）属性类。表示问题环境的某些重要性质（例如，在抵押贷款应用语境中的信用级别）。

       （3）交互类。模拟在其他对象间发生的交互（例如，购买或执照）。
 

       此外，对象和类可以按以下特征进行分类。

       （1）有形性（tangibilty）。类是表示了有形的事物（如，键盘或传感器），还是表示了抽象的信息（如，某预期的输出）。

       （2）包含性（inclusiveness）。类是原子的（即，不包含任何其他类），还是聚合的（包含至少一个被嵌套对象）。

       （3）顺序性（sequentiality）。类并发的（即，拥有自己的控制线程），还是顺序的（被外面的资源控制）。

       （4）持续性（persistence）。类是短暂的（即，在程序运行中被创建和删除）、临时的（在程序运行中被创建，在程序终止时被删除），还是永久的（存放在数据库中）。

       （5）完整性（integrity）。类是易被侵害的（即，没有保护资源不受外界的影响）、还是被保护的（类加强对其资源访问的控制）。

       基于上述类的分类，要对作为CRC模型一部分的“索引卡片”扩展以包含类的类型及其特征。

       2）责任

       郑州apple软件开发认为责任也就是属性和操作。属性表示类的稳定特性，即为了完成客户规定的软件目标所必须保持的类的信息，一般可以从对问题的范围陈述中抽取出或通过对类的本质的理解而辨识出属性。可以通过对系统的过程叙述进行语法分析而抽取出操作，动词作为候选的操作，每个为类选择的操作展示了类的某种行为。将责任分配到类有以下五条指南。

       （1）应该平均地分布系统智能。每个系统均包含一定程度的智能，即系统知道什么会做什么。智能可以以一系列不同的方式在类间分布，“废物（dump）”类（几乎没有责任的类）作为“聪明（smart）”类（有很多责任的类）的服务提供者。虽然该方法使系统中的控制流程直接明了，但它也有一些缺点：它将所有智能集中在一些类中，使修改更为困难；需要更多的类从而导致需要更多的开发工作量。

       因此，系统智能应该在应用的类之间平均分布。因为每个对象仅仅知道并做少量的事情（它们通常是被很好聚焦的），从而系统的内聚性得到改善。此外，因为系统智能已经被分布在很多对象间，由于变化而引起的副作用将被减弱。

       为确定系统智能是否已被平均分布，须评估每个CRC模型索引卡片上的责任列表，确定是否某个类具有特别长的责任列表，这表明存在智能的集中。此外，每个类的责任应该有相同的抽象层次，例如，在一个称为账户检测的聚合类的操作列表中，有两个责任：平衡账户和标记检测过的记录，第一个操作（责任）蕴含了复杂的数学和逻辑过程，第二个操作是一个简单的书记性活动。因为这两个操作在不同的抽象层次，标记检测过的记录应该包含在聚合类账户检测中的类检测工作的责任中。

       （2）责任应该尽可能通用性地加以陈述。这个指南指出通用性责任（属性和操作）应存在于类层次的高层（因为它们是类属的，它们适用于所有子类）。此外，多态应该用来定义总体上适用于超类但在每个子类中有不同实现的操作。

       （3）信息和与其相关的行为应该存在同一类中。这体现了我们称为封装的面向对象原则，数据和操纵该数据的处理应该作为内聚的单元来封装。

       （4）关于一个事物的信息应该包含在单个类中，而不是分布在多个类中。单个类应该承担存储和操纵特定信息类型的责任，通常，该责任不应该由一组类分享。如果信息被分布，软件将变得更难于维护及测试。

       （5）当适当时候，在相关类间分享责任。在很多情况下，一系列相关对象必须同时展示相同的行为。作为一个例子，考虑必须显示下列对象的视频游戏：玩家、玩家身体、玩家胳膊、玩家头部，每个对象均有自己的属性（例如，位置、朝向、颜色、速度），并且当用尸操纵游戏杆时，所有对象必须被更新和显示。因此责任更新和显示必须被上面的每个对象分享，当某些东西改变时，玩家要知道所发生的改变并进行更新，它和其他对象协作以完成新的位置或方向，但是每个对象控制自己的显示。

       3）协作者

       类以以下两种方式之一完成它们的责任：①类使用它自己的操作去操纵它自己的属性，从而完成某一特定责任；②类可以和其他类协作。

       郑州苹果软件开发认为协作的定义是：协作表示了为完成客户的责任，对客户服务器的请求。协作是在客户和服务器间合约的具体体现。如果为了完成某责任，一个对象需要向其他对象发送任何消息，则我们说该对象和另一个对象协作。单个协作流是单方向的——表示从客户到服务器的请求。从客户的观点来看，它的每个协作是和服务器实现某特殊责任相关联的。

       协作标识了类之间的关系。当一组类一起协作以完成某需求时，可将它们组织为子系统（这是一个设计问题）。

       通过确定类是否可以自己完成每个责任来标识协作，如果不能，则它需要和另一个对象交互，因此，产生协作。

       假设考虑一个具体的带有传感器的安全系统例子。作为启动过程的一部分，控制面板对象必须确定是否任一传感器是打开的，相应定义一名为“确定传感器状态”的责任。如果传感器是打开的，控制面板对象必须将状况属性设置为一未准备好”。可以从传感器对象获取传感器的信息。因此，仅当控制面板和传感器协作时才可以完成责任“确定传感器状态”。

       郑州android开发认为为了帮助标识协作者，分析员可以检查类之间的三种不同的类属关系：①部分（is-part-of）关系；②获知（has-knowledge-of）关系；③依赖（depends-upon）关系。通过创建一个类一关系图，分析员开发出标识这些关系所必须的连接。在下面的篇幅中，概略地讨论三种类属关系。

       所有是某聚合类的一部分的类通过is－part－of关系同该聚合类连接。考虑前面提到的为视频游戏定义的类，类玩家身体同类玩家是is－part－of关系，玩家胳膊、玩家腿部和玩家头部与玩家间也是同样的关系。

       当一个类必须从另一个类获取信息时，就建立hasknowledge-of关系。前面提到的determln-sensor-status责任是他于knowledge宁of关系的一个例子。

       depends－upon关系表示着两个类间存在由has-knowledge-of或is-part-of所不能完成的依赖关系。例如，Player-head必须总是和Playeybody相连接（除非该视频游戏是特别暴力的），但每个对象仍可以在不直接知道另一个对象的情况下存在。playerhead对象的一个称为“中心位置”的属性，将根据玩家身体对象的中心位置属性来确定，该信息是通过第三个对象玩家从对象玩家身体获取的，因此，玩家头部depends－upon玩家身体。

       在所有情形，将协作者类名记录在CRC模型的索引卡片上衍生出该协作的责任的旁边，因此，索引卡片包含一组责任和使得责任能够被完成的相应的协作。

       郑州安卓软件开发认为当已建好了一个完整的CRC模型后，来自客户和软件工程组织”的代表可以使用下面的方法追览该模型。

       （1）给所有参加（CRC模型）复审的人一个CRC模型索引卡片的子集，有协作关系的卡片要分开（即，没有任何复审者持有两张有协作关系的卡片）。

       （2）应该将所有用例场景组织为种类。

       （3）复审的负责人仔细地阅读用例，当复审负责人遇到一个命名对象时，他将令牌传送给持有对应的类索引卡片的人员。

       （4）当传送令牌时，类卡片的持有者要描述卡片上记录的责任，小组将确定是否一个域多个）责任满足用例需求。

       （5）如果索引卡片上的责任和协作不能适应用例，则需对卡片进行修改、这可能包括定义新类（及相应的CRC索引卡片）或在现存卡片上刻画新的或修订的责任或协作。这种做法持续至用例完成。

       CRC模型是第一个关于面向对象系统的分析模型的表示，可以通过进行从系统导出的被用例所驱动的复审来进行测试。

       定义结构和层次

       郑州ios开发认为一旦已经使用CRC模型标识了类和对象，分析员开始关注类模型的结构及由类和子类所引致的类层次。建议应该从已标识的类中导出其一般——特殊结构。

       定义主题和子系统

       复杂系统的分析模型可以包含成百个类和许多个结构，为此，有必要定义一种简洁的表示法，它是前面描述的CRC和结构模型的摘要。

       当类的某个子集相互协作以完成一组内聚的责任时，它们常被称为主题）或子系统。主题和子系统都是一种抽象，提供了指向分析模型中更细节内容的引用或指针。当从外界观察时，主题或子系统可被视为黑盒子，它包含了一组责任并且有自己的（外界）协作者。子系统和其外界协作者间实现一份或多份合约，一份合约是协作者可以对子系统进行的一组特定请求的清单。

       郑州plc开发认为子系统可以在CRC建模的语境内通过创建一个子系统索引卡片来表示。子系统索引卡片标明子系统的名字、子系统必须服务的合约以及支持合约的类或（其他）子系统。

       转载请注明出处：郑州知网软件  http://www.nwisdom.com