《软件工程》课件第14章

第14章面向对象开发方法14.1面向对象基本问题14.2面向对象开发方法和过程14.3业务建模14.4需求14.5分析14.6设计14.7实现ZLL14.1面向对象基本问题——14.1.1面向对象的基本概念

1对象是现实世界事物或个体的抽象表示，抽象的结果不仅包括事物个体的属性，还包括事物的操作。对象属性值表示了对象的内部状态，操作表示了对象可以完成的职责。在分析阶段，对象的操作是对象展现给外部的服务。对象状态的改变是由对对象的操作引起的。对于民航机场的指挥控制系统，MU9114航班就是该问题域中的对象，该对象的属性可以包含但不限于：航班号、起飞机场、降落机场、起飞时间、降落时间，位置等；可能的操作包括离港、到港等。当对MU9114航班对象进行离港操作时，对象的状态将从停靠状态改变成飞行状态。对于学生管理系统，06-2班也是一个问题域内的对象，其属性包括班级成员、班长、固定教室等，其操作可包括分配教室等等。ZLL14.1面向对象基本问题——14.1.1面向对象的基本概念

2.类

类是对具有共同特征的对象的进一步抽象。类通常被认为是对象的模板，通过该模板可以创建特性一致的对象。使用类创建对象的过程实际上是类的实例化过程。

民航机场的指挥控制系统中，从众多的航班对象可抽象出一个航班类，通过这个类，反过来可以实例化很多的对象：MU9114、MU9115等等。而在学生管理系统中，通过对04-2、05-1等对象的抽象，形成班级类。一旦有了班级类，又可以实例化出更多班级，如07-1、08-2等等。ZLL14.1面向对象基本问题——14.1.1面向对象的基本概念

3.关系关系用于表达相关事物之间的关联

考虑一个家庭，以及家庭内部所有成员之间的关联，就可以很好的理解关系的概念。关系表示了事物之间语义上的联系。比如父亲和孩子之间就有语义上的联系，这就是关系。关系可以按照语义分很多种，经常涉及到的就是继承、关联、依赖等。ZLL14.1面向对象基本问题——14.1.1面向对象的基本概念

4.继承继承关系模拟了现实世界的一般与特殊的关系它允许我们在已有的类的特性基础上构造新类。被继承的类我们称之为基类（父类），在基类的基础上新建立的类我们称之为派生类（子类）。派生类的特性比基类的特性更细致。比如以生物类作为基类，派生出动物类，动物类具备生物类的全部特性（生长，新陈代谢等），但同时他必须是能活动的生物。继承关系可以表述为：派生类是基类。因此可以说：动物是生物。生物比动物具有更一般的特性。ZLL14.1面向对象基本问题——14.1.1面向对象的基本概念

5.聚合聚合关系是关联关系的一种，它模拟了现实世界的部分与整体的关系。聚合关系允许利用现有的类组成新类比如说汽车，它是由发动机、变速箱、底盘等组成，那么我们就可以利用发动机、变速箱、底盘等类聚合成一个新的类：汽车。因为聚合是部分与整体的关系，因此，不能像继承关系那样说汽车是发动机，正确的说法应该是：发动机是汽车的组成部分。ZLL14.1面向对象基本问题——14.1.1面向对象的基本概念

6.消息消息是对象之间交互的唯一途径，一个对象要想使用其他对象的服务，必须向该对象发送服务请求消息。而接收服务请求的对象必须对请求做出响应。当我们向银行系统的帐号对象发送取款消息时，帐号对象将根据消息中携带的取款金额对客户的帐号进行取款操作：验证帐号余额，如果帐号余额足够，并且操作成功，对象将把执行成功的消息返回给服务请求的发送对象，否则发送交易失败消息。ZLL14.1面向对象基本问题——14.1.1面向对象的基本概念

7.多态多态并没有统一规范的定义，可以从生物学的角度来理解这个概念。比如所有动物都有一个能运动的特性，也就是说运动是动物的固有属性，可是动物究竟怎么运动却无法准确的描述出来。由于生物进化过程存在多样性，所以会有鸟、鱼、蛇，老虎等等，这种多样性就导致了不同动物的运动方式是不一样的，比如鱼是游动，蛇是爬行等等。多态就是来解决这样的问题的。动物是多样的，当让动物移动的时候，如果这个动物是蛇，那这个移动就是爬行，而如果这个动物是鱼，他就会游动。可以通过图14-1简单的理解多态的概念。AnimalMove()BirdFishTigerSnakeZooStart()for(i=0;i<Ancount;i++){Animalan=GetAnimal(i);an.Move();}ZLL14.1.2面向对象的编程面向对象编程用以实现面向对象的基本概念，比如类、对象、继承、多态等概念。面向对象的语言和面向对象的编程是不同的，面向对象语言在语言级别上直接支持面向对象的概念，如JAVA语言和C++语言中的关键字class是对类这个概念的直接支持。面向对象的编程是一种编程思想，可以用面向对象的语言来实现，当然也可以不用面向对象的语言来实现。比如用C语言的结构和函数指针也可以实现类的概念。通常情况下，面向对象的编程是指用面向对象语言来实现面向对象的分析和设计概念，这些概念如类、继承、多态等等。面向对象的语言必须直接支持如下概念：对象封装；类和实例；继承；多态。ZLL14.1.2面向对象的编程1．类、对象面向对象语言首要支持的概念就是对象，对象不仅包含属性还包括操作，软件系统中，对象不是孤立存在的，每个对象都要与其他对象进行交互，每个对象都会有定义良好的接口为其他对象提供服务。比如车老师这个对象，他有教龄属性，有学历属性，他要教课，当然也要学习。教课就是车老师提供的服务，教学这个服务由学院来启动，启动的时候还要传进来一些参数，比如教什么课，教哪个班级，课表等。一旦车老师开始教04级的《软件项目管理》这门课程，他同04级所有的学生又有交互，比如提问，批作业等等。在面向对象的程序中，对象的属性通过变量来实现，对象的操作通过方法（或函数）来实现。ZLL14.1.2面向对象的编程上图说明chejinhui是Teacher类的一个对象，他的教龄是7年，毕业学校是沈阳工业大学，他可以教学，还可以学习。根据问题域内的诸多具有共同属性和服务的对象可以抽象出适当的类来，比如曹老师、姜老师，虽然他们有很多的属性和责任，比如身高、体重、所教的课程，缴纳个人所得税等等，但是在教务管理这个问题领域里面只需要抽取与教务有关的属性和服务，比如所教的课程、班级、使用的教室等等。Chejinhui:TeacherteacheYears=7graduateUniversity=”ShenyangPolitechnic”teach(Coursecse，SClasscls，Schedulescd)study()ZLL14.1.2面向对象的编程在面向对象的分析与设计中，根据属性和服务抽象出相应的类，在面向对象的程序设计过程中，往往是个相反的过程，也就是先定义类，然后通过类来创建相应的对象。图14-3表达了Teacher类。其中第一框是类名，第二框中放的是类的属性，第三框中放的是类提供的服务。TeacherteacheYearsgraduateUniversityteach(Coursecse，SClasscls，Schedulescd)study()ZLL14.1.2面向对象的编程以上类和对象的JAVA实现就是：classTeacher{intteacheYears;StringgraduateUniversity;publicTeacher(intteacheYears，StringgraduateUniversity){this.TeacheYears=teacheYears;this.GraduateUniversity=graduateUniversity;}publicvoidteach(Coursecse，SClasscls，Schedulescd){}protectedstudy(){}；}在需要教师教课的地方就可以出现如下代码Coursecse=newCourse(“软件项目管理”);SClasscls=newSclass(“06-1”);scdSchedule=newSchedule(5，3，”1403”)//星期五第三节在1403授课Teacherchejinhui=newTeacher(7，”chejinhui”);chejinhui.teach(cse，cls，scd);这段代码会创建一个Teacher类的对象，并使用它提供的服务teach为学生授课。ZLL14.1.2面向对象的编程//基类abstractclassAbstractAdd{priavatefloatoperandA;privatefloatoperandB;publicabstractvoidgetOperands();publicfloatadd(){returna+b;}publicfloatgetResult(){getOperand();returnadd();}//派生类classFileAddextendsAbstractAdd{publicvoidgetOperands(){try{ FileInputStreamfis=newFileInputStream(“operants.dat”); DataInputStreamdis=newDataInputStream(fis); OperandA=dis.readFloat(); OperandB=dis.readFloat(); } catch(Exceptione){} finally{dis.close();fis.close();}}ZLL14.1.2面向对象的编程3．多态面向对象的语言提供两种形式的多态，一种是静态的多态，另一种是动态的多态，动态多态是真正意义的多态。静态的多态通常也被称为早绑定（earlybingding）或者静态绑定（staticbinding）。静态多态的方法是在编译阶段绑定的，所以效率高。动态多态通常也被称为晚绑定（latebinding）、延迟绑定（delayedbinding）或虚绑定（virtualbinding）。动态绑定的方法是在运行时被绑定的。C++支持动态和静态绑定，通过静态绑定即实现了多态而且效率也比较高，JAVA则只有动态多态，所有的方法都是在运行时被绑定的。下面给出一个C++静态多态的例子。ZLLclassAnimal{public:voidmove(Point2Dfrom，Point2Dto);//①voidmove(Point3Dfrom，Point3Dto);//②};voidAnimal::move(Point2Dfrom，Point3Dto){//在2维空间，也就是平面上移动}voidAnimal::move(Point3Dfrom，Point3Dto){//在3维空间内移动}intmain(){Aniaml*an=newAnimal;Point2Dfrom2d，to2d;Point3Dfrom3d，to3d;an->move(from2d，to2d);//③an->move(from3d，to3d);//④}14.1.2面向对象的编程编译器在编译③和④语句时，会分别将函数调用指向①和②，静态绑定时，编译器会通过多态函数的参数类型进行匹配从而在编译时期决定具体调用哪个函数，这是静态多态。C++的动态多态必须用virtual关键字进行明确的指示，而且即使已声明为动态多态的函数也可以用强制的方法进行静态绑定，凸显了C++在效率和面向对象概念支持上的灵活性。ZLL下面给出图14-1类图的JAVA实现

abstractclassAniaml{//既然不知道是什么动物，当然也不知道一个动物如何从一个地方移动到另一个地方，move的实现将延迟到子类中publicabstractvoidmove（Pointform，Pointto）;}classFishextendsAnimal{publicvoidmove（Pointform，Pointto）{System.out.println(“Iswimfrom“+from.axis+”to”+to.axis);}pbulicBirdextendsAnimal{publicvoidmove（Pointform，Pointto）{System.out.println(“Iflyfrom“+from.axis+”to”+to.axis);}pbulicTigerextendsAnimal{publicvoidmove（Pointform，Pointto）{System.out.println(“Irushfrom“+from.axis+”to”+to.axis);}不同的面向对象语言对面向对象的概念的支持程度不一样，因此在开发语言的选择上也要有个权衡。14.1.2面向对象的编程ZLL14.1.2面向对象的编程//基类abstractclassAbstractAdd{priavatefloatoperandA;privatefloatoperandB;publicabstractvoidgetOperands();publicfloatadd(){returna+b;}publicfloatgetResult(){getOperand();returnadd();}//派生类classFileAddextendsAbstractAdd{publicvoidgetOperands(){try{ FileInputStreamfis=newFileInputStream(“operants.dat”); DataInputStreamdis=newDataInputStream(fis); OperandA=dis.readFloat(); OperandB=dis.readFloat(); } catch(Exceptione){} finally{dis.close();fis.close();}}ZLL14.1.3结构化与面向对象结构化方法是经典的软件开发方法，结构化方法对现实世界的划分是以过程（对数据的加工）为核心的，信息从外部实体流入系统，经过系统的加工处理后流出系统到外部实体。可以用图14-4来表达。TomHouseCarTreelivedrivepassTomHouseCarTree现实世界模型语义断层其表达的含义是，Tomliveinahouse，Tomdriveacarpassingatree。在映射过程存在较大的语义断层，也就是说，结构化模型不能准确地表达现实世界。ZLL14.1.3结构化与面向对象传统的结构化方法分离了信息和对信息的加工过程，系统的分析以加工过程为核心，伴随对信息数据的分析过程。信息和信息加工的分离首先会导致维护的困难，因为相关的加工过程必须知道数据的存储方式，一旦信息格式和存储方式发生改变，这种修改将扩散至所有相关的加工过程。其次，结构化方法在需求和分析过程中存在较大的语义断层。在需求阶段得到的需求经常是用自然语言来表达的，比如“用户可以存款”、“学生可以选课”，这些自然语言表达的需求可为开发方和客户方所共同理解，当然客户对这样的自然语言的理解是没有问题的。当用结构化的方法对需求进行分析的时候，我们已经把系统是什么直接转化成了系统是怎么实现的了，这样在需求和分析之间就存在了较大的语义断层。也就是在系统的外部视图（客户角度来看系统）和内部视图（开发的角度来看系统）间存在较大的断层。虽然结构化开发方法存在不足之处，但是在实时系统，操作系统，应用底层，嵌入式等领域依然有着广泛的应用。ZLL14.2面向对象开发方法和过程——14.2.1面向对象方法

软件工程包括工具、方法和过程，这里的面向对象开发方法（objectorientedapapproach）指的是与面向对象相关工具（tools）、方法（method）和过程（process的技术总和）。如无特殊声明本书所称面向对象的方法指的是objectorientedapapproach，而非method。本小节在简单的介绍几种面向对象分析方法的基础上，重点介绍如何利用Coad／Yourdon的OOA方法对系统进行面向对象的需求分析。ZLL14.2面向对象开发方法和过程——14.2.1面向对象方法

1．OMT方法对象建模技术（ObjectModelingTechnique，OMT）由Rumbaugh等提出，其目的是不断对系统设计进行细化，直到最后的模型适合于实现为止。OMT方法包含五个步骤：（1）分析：对问题域进行分析建模。（2）系统设计：对系统的整体体系结构进行设计。（3）对象设计：对系统中的对象结构进行细化并为之添加细节。（4）编码：用面向对象的语言实现所设计的类。（5）测试：验证系统的正确性。由于OMT是个迭代的过程，上述步骤可能被重复执行多次，才能得到符合要求的系统ZLL14.2面向对象开发方法和过程——14.2.1面向对象方法

OMT在分析阶段的任务。（1）编写问题陈述：编写问题域的陈述。（2）建立对象模型：识别类和类之间的关系，为类准备数据字典。（3）建立动态模型：动态模型主要用于描述对象之间的关系随时间的变化。（4）建立功能模型：功能模型采用过程描述工具（数据流图）来描述系统中数据的加工过程。（5）对象模型、动态模型和功能模型进行细化，并建立相应的文档。从OMT模型分析阶段的任务可以看出，OMT不仅在分析阶段创建了描述对象系统的对象模型和动态模型，还吸取了结构化分析的有力工具：数据流图和数据字典，从而使面向对象系统的描述更完整。ZLL14.2面向对象开发方法和过程——14.2.1面向对象方法

2．Booch方法Booch方法提出了描述对象系统的两个模型：用于描述逻辑结构的逻辑模型（LogicalModel）和描述系统物理结构的物理模型（PhysicalModel），而对于这两个模型又可以采用描述系统静态侧面的静态模型（StaticModel）和描述系统动态特性的动态模型（DynamicModel）两种方式来描述。Booch方法是一个迭代的、渐进式的系统开发过程。Booch方法把分析和设计过程分为宏过程和微过程两个过程。微过程定义了一组在宏过程中的每一步反复应用的分析任务。其中的宏过程包括下面5个活动：（1）概念化：建立核心需求。（2）分析：为所期望的行为建立模型。（3）设计：建立体系结构。（4）进化：形成实现。（5）维护。ZLL14.2面向对象开发方法和过程——14.2.1面向对象方法

2．Booch方法微过程基本上代表了开发者的日常活动，由四个重要的、没有顺序的步骤组成：（1）在给定的抽象层次上识别出类和对象；（2）识别类和对象的语义(属性和操作)；（3）识别出类间和对象间的关系；（4）实现类和对象。Booch方法为面向对象系统的设计提供了详细的方法指导，但是对分析阶段的描述则显得过于简单。ZLL14.2面向对象开发方法和过程——14.2.1面向对象方法

3．OOSE（ObjectOrientedSoftwareEngineering）方法OOSE是用例（usecase）驱动的方法。在该方法中，用例模型是分析阶段的模型。用例模型主要用来描述系统外部角色（Actors）和软件系统为这些外部角色提供的服务和功能。比如银行系统中的转帐功能就是客户角色的一个用例。通过确定系统外部角色与系统内部功能的交互作用，用例模型描述了系统的完整功能。OOSE的分析阶段，要构造两种模型：需求模型和分析模型。需求模型从用户的角度描述了系统具有的所有功能。需求模型由用例模型、问题域对象模型和接口描述三部分组成。用例模型描述了角色和用例及用例和角色之间的关系。角色描述了使用系统功能的外部实体，它可以是由人承担的角色，也可以是外系统。分析模型是通过对接口对象、实体对象和控制对象的分析和描述而建立的模型。接口对象、实体对象和控制对象可以完成用例视图所要求的全部功能。OOSE方法的最大的贡献就是引入了用例的概念。ZLL14.2面向对象开发方法和过程——14.2.1面向对象方法

4．Coad/Yourdon的OOA/OOD方法Coad/Yourdon面向对象的方法包含识别对象、标识对象的属性和行为、识别对象所属的类、定义主题词等步骤，这些步骤之间并无严格的边界，比如可以在识别对象的同时标识对象的属性和行为。（1）识别对象1）标识潜在的对象①外部实体②信息域内的概念实体③需记忆的系统事件④角色⑤场所、位置⑥组织机构⑦聚集对象潜在对象理由银行（Bank）帐号（Account）资金（Funds）客户（Client）交易（Transaction）概念实体概念实体概念实体外部实体事件对象下面是银行系统的需求描述，根据描述识别潜在的对象如表14-1所示。银行系统的需求描述：①一个银行可以有多个帐号。②一个银行可以有多个客户。③一个客户可以持有多个帐号。④一个帐号可以被多个客户持有。⑤可以开户、注销帐户、存钱、取钱、银行内转帐、银行间转帐2）筛选对象并不是所有的对象都会进入需求分析模型。在标识潜在的对象之后应该采用下面的原则对潜在的对象进行筛选，符合条件的对象方可进入需求分析模型。①对象应具有记忆自身状态的能力。并且对象的属性应该是系统所关心的，或者是目标系统所必须的。②对象应具有有意义的操作，以某种方式修改其状态。并且，对象应利用其操作为目标系统中的其他对象提供外部服务。③对象应具有多种意义的属性。仅有一种属性的对象最好表示为其他对象的属性。④对象的属性和操作应该适用于对象的所有实例，这是对象所必须具备的基本条件。ZLL14.2面向对象开发方法和过程——14.2.1面向对象方法

4．Coad/Yourdon的OOA/OOD方法2）筛选对象①对象应具有记忆自身状态的能力。②对象应具有有意义的操作，以某种方式修改其状态。③对象应具有多种意义的属性。④对象的属性和操作应该适用于对象的所有实例(基本条件)。⑤对象应是软件需求模型的必要成分，与设计和实现方法无关。潜在对象理由银行（Bank）帐号（Account）资金（Funds）客户（Client）交易（Transaction）符合①～⑤符合①～⑤概念实体不符合③符合①～⑤符合①～⑤表14-2银行系统潜在对象的筛选结果在UML中类用上图14-6所示符号表示，其中第一框为类名，第二框为类的属性，第三框是类的行为。ZLL4．Coad/Yourdon的OOA/OOD方法（2）标识对象的属性对象属性的组合标明了对象状态，而对象状态的改变则依赖于对对象的操作。在标识对象属性的过程中，分析人员要保证识别出来对象的属性落在所分析系统的信息域内。为了更准确的标识对象的属性，分析人员还要认真的研究用户的需求陈述，从中找到关键的形容词和带所有格的名词。为了防止冗余的、不正确的属性，在识别对象属性的过程中应该注意以下问题。①去除对象的导出属性。②去除外部不可见状态。③属性不适用于全部对象④仅有一种属性的对象可以表示为其他对象的属性，而不需要单独作为一个对象来实现。⑤对于对象的某种属性，如果该对象的特定实例会有多重属性值，则应该将对象分成两个对象。14.2面向对象开发方法和过程——14.2.1面向对象方法

ZLL（3）识别对象的行为对象的行为是对象所能完成的功能，也是对象所展现外部服务的总和。在面向对象的系统中，对象的职责和功能完全是由对象提供给其他对象的服务来定义的。对象的操作以外界的可见性可分为服务和内部操作。其中内部操作是为了完成服务功能而定义的对象内部操作，这种操作不为对象的外部可见，是对象职责的实现细节，因此不是分析阶段描述的内容。而服务则是对象提供给外界对象的操作接口。是分析阶段要描述的重要内容。通常将对象的行为分为三类：①对象生存期行为，包括对象的创建、维护和销毁行为；②计算性行为；③监视性行为或称状态-事件-响应行为。而识别对象的行为则通过如下的过程：①提取对象外部行为的大致功能和名称，同时进行适当的精化；②标识对象之间的消息传递；③使用模板描述对象的外部服务和对象间的消息传递，所谓模板是软件组织制定的用于描述对象行为的标准格式。14.2面向对象开发方法和过程——14.2.1面向对象方法

ZLL1）提取外部服务外部服务的提取依然依赖于客户对问题的文字性描述。分析人员通过对问题陈述的分析，得到可以作为对象外部服务的动词。①对象生存期行为分析②对象计算性行为分析③对象监视性行为分析比状态-事件-响应表更为有效的工具是对象状态图。CreateDestroyChange图14-7对象生存期状态事件

响应（状态）opencloseclosedcloseopenopenedopenwriteoffwirteoffclosewriteoffwriteoffwriteoffCloseopenwriteoffOpenCloseWriteoffZLL2）标识对象间的消息传递对象之间的交互和通信是由对象之间的消息传递来实现的。消息的传递过程涉及到三个方面：一是消息的发送者，二是消息的接收者，三就是消息本身。通常，消息可分为以下几类：①Obj1激活Obj2；如在Obj1中使用CreateObj2()创建Obj2。②Obj1提供信息给Obj2；如在Obj1中使用Obj2.SetPara()，用于设置Obj2的某些属性。③Obj1询问Obj2；如在Obj1中使用Obj2.GetPara()获得Obj2的基本属性或导出属性。MessageObj1Obj2图14-9消息传递④Obj1命令Obj2完成某项功能。如调用Obj2.SendData()发送数据。图14-9示出了Obj1向Obj2发送消息Messge的情况MessageObj1Obj2图14-9消息传递ZLL3）外部服务的表示在面向对象的系统中，不仅要正确地识别对象所应提供的外部服务，还要采用一定的策略对外部服务进行筛选和精确描述。下面给出筛选和描述对象外部服务的策略：①只有外部可以观察的行为才构成外部服务；②使用统一的模板或工具描述对象及其外部服务；③使用简洁、精确、无歧义的文字描述外部服务的处理步骤和功能。在系统分析阶段，对象行为的定义只局限在对象的外部行为上，也就是说，对象该具有怎样的职责，至于对象职责的实现细节，则是面向对象设计的任务。软件组织可以通过制定标准的面向对象的分析和设计模板来规范分析和设计的结果。也可以通过使用CASE工具来描述它。在CASE工具中对外部服务的描述可以使用活动图对服务过程进行详细的描述。以使分析员、客户、和其他项目组成员在对象的职责上达成共识。ZLL（4）识别对象所属的类具有共同特性的对象可以抽象成类，抽象出来的类又可以实例化成对象。在面向对象的方法中。每个对象都是通过实例化类来创建的，因此每个对象应该有自己所属的类。面向对象的需求模型中，对象可能属于不同的类，这些类之间可能存在继承关系和聚合关系。因此在面向对象方法的分析阶段，主要任务就是标识对象所属的类并建立类之间的继承关系和聚合关系。ZLL（5）定义主题词当分析模型中的某些类具有很大的相关性、且用于完成一组内聚性很高的功能时，我们可以把这些类定义到一个主题词下。主题词的定义应该遵循如下策略：①由经验丰富的的分析人员标识系统的对象和类，在此基础上将紧密结合的类划分到同一个主题词下。②根据主题词将需求分析的任务划分给各个分析小组。③随着分析的进行，主题词可以按照树状结构继续划分，直到主题词的内容是类而不是主题词为止。银行系统的主题词通常可划分为如图14-10所示的三个主题词。人机界面主题词下还可进一步细分为前台主题词和分析主题词，如图14-11所示人机界面银行业务数据操作前台分析ZLL14.2.2Rational统一过程（RationalUnifiedProcess，RUP）

软件工程过程定义了软件开发的whowhatwhen和how，它是由诸多相互作用的活动构成的。每个活动都通过一定的方法将输入转变成一定的输出。活动通常是由人参与，在一定的资源限制下完成的。比如软件过程中的测试，它的输入是代码、测试用例、测试计划等，参与的角色主要是测试员，测试管理员等，测试员通过一定的方法对代码进行测试，最终产生软件的质量评价和软件缺陷的修改意见。统一过程（UnifiedProcess，UP）是一个开放的软件工程过程。迭代、螺旋、增量是UP的核心思想。RUP（RationalUnifiedProcess）是UP的一个商业版本。确切的说，RUP是UP的一个实例。RUP提供在开发机构中分派任务和责任的方法，其目标是在可预见的日程和预算前提下确保满足最终用户需求的高质量软件的产生。RUP是一个可裁减的过程，RUP为配置适合特定需要的开发过程提供了支持，因此RUP适用于规模从小到大的各类软件的开发。RUP的二维结构包括时间和过程组件两个轴，为使软件项目开发成功，两个轴都要被考虑。其中业务建模、需求、分析和设计、实施、测试和部署是RUP的核心过程工作流。配置和变更管理、项目管理、和环境是RUP的核心支持工作流。ZLL1．时间轴（1）先启阶段，也叫初始阶段其主要任务是建立软件系统的业务模型，需要考虑项目的效益，并进行初步的需求分析这一阶段需要与系统的用户和领域专家进行讨论。（2）精化阶段，又叫细化阶段其主要任务是分析问题域，建立坚实的体系结构基础、制定项目计划、消除项目中高风险因素。（3）构造阶段在构造阶段，系统的新特性被开发并集成到产品中，所有的新特性都被充分和彻底的测试。（4）产品化阶段（即移交阶段）主要任务是部署和配置系统，并将产品交付给用户。ZLL2．工作流（Workflows）沿着过程组件轴，过程被划分为核心过程工作流(CoreProcessWorkflows)和核心支持工作流(CoreSupportingWorkflows)。工作流是由活动构成的活动序列。过程组件轴的每个活动都应用于时间轴的每个阶段，例如，构造阶段是由多次迭代组成，每一次迭代都包含商业建模、需求、分析和设计、实现和测试，在构造的最后一次迭代还应包括配置，每次迭代所得到的产品应满足项目需求的某一个子集，或被提交给用户，或是软件组织内部提交。每一次迭代都包含了软件生命周期的所有阶段。活动在各个阶段应用的程度由开发阶段决定。例如，在初始阶段，商业建模的工作要比需求工作多；在细化阶段，分析与设计的工作要比实现的工作多；系统的实现主要发生在构造阶段；系统的配置工作主要发生在交付阶段。ZLL3．微过程的划分由图14-12可以看出，每次迭代通常都包含一个微过程，微过程是由上述九个工作流组成。每个微过程的任务类似于瀑布模型的各个阶段，这里不再详述。ZLL14.2.3面向对象的工具面向对象的分析方法给了我们如何对面向对象系统进行需求分析的方法指导。但是我们却不能离开面向对象的分析工具的支持。多年来，面向对象的工具从手工逐渐走向计算机辅助工具，从不规范走向规范，这期间Rational（现已被IBM公司兼并）公司做出了巨大的贡献。其遵循UML标准的CASE工具RationalRose集面向对象分析、面向对象设计、测试、代码框架生成、逆向工程等工具于一身。在构建面向对象系统的整个过程中，除编码之外，我们可以不离开RationalRose的工具环境，就能生成软件工程全部配置。设计视实现视过程视配置视用例视ZLL14.2.4统一建模语言(UML)UML结构包括三个组成部分，如图14-14所示。UML要素通用机制架构ZLL1．要素（buildingblocks）

包括基本的模型元素(elements)、关系和图。（1）基本模型元素①结构事物（Structuralthings）类（Class）：类是指具有相同属性、方法、关系和语义的对象的抽象；接口（Interface）：接口是指类或组件所提供的服务（操作），描述了类或组件对外可见的操作；协作（Collaboration）：协作描述合作完成某个特定任务的一组类及其关联的集合，用于对使用情形的实现建模；用例（UseCase）：用例定义了执行者和被考虑的系统之间的交互来实现的一个业务目标；活动类（ActiveClass）：活动类的对象包含一个或多个进程或线程。活动类和普通类很相象，只是活动类的操作与调用这个操作的类的操作不在一个进程（线程）中；组件（Component）：组件是物理的、可替换的部分。“组件是物理的”体现了组件是计算机系统中的一个实体，比如一个JAVA包、一个动态库等；结点（Node）：结点是系统赖以运行的物理元素，也是一个可计算的资源，通常情况下结点是指一台具有一些内存和处理能力的计算机。ZLL1．要素（buildingblocks）

包括基本的模型元素(elements)、关系和图。（1）基本模型元素①结构事物（Structuralthings）类（Class）：类是指具有相同属性、方法、关系和语义的对象的抽象；接口（Interface）：接口是指类或组件所提供的服务（操作），描述了类或组件对外可见的操作；协作（Collaboration）：协作描述合作完成某个特定任务的一组类及其关联的集合，用于对使用情形的实现建模；用例（UseCase）：用例定义了执行者和被考虑的系统之间的交互来实现的一个业务目标；活动类（ActiveClass）：活动类的对象包含一个或多个进程或线程。活动类和普通类很相象，只是活动类的操作与调用这个操作的类的操作不在一个进程（线程）中；组件（Component）：组件是物理的、可替换的部分。“组件是物理的”体现了组件是计算机系统中的一个实体，比如一个JAVA包、一个动态库等；结点（Node）：结点是系统赖以运行的物理元素，也是一个可计算的资源，通常情况下结点是指一台具有一些内存和处理能力的计算机。②行为事物（Behavioralthings）③分组事物（Groupingthings）④注释事物（Annotationalthings）ZLL1．要素（buildingblocks）

包括基本的模型元素(elements)、关系和图。（1）基本模型元素②行为事物（Behavioralthings）行为事物指的是UML模型中的动态部分，代表语句里的“动词”，表示模型里随着时空不断变化的部分，包含两类：交互（interaction）：交互是由一组对象为达到特定的目的而进行的一系列消息交换所组成的动作；状态机（statemachine）：状态机由一系列对象的状态组成。③分组事物（Groupingthings）可以把分组事物看成是一个“盒子”，模型可以在其中被分解。目前只有一种分组事物，即包（package）。结构事物、动作事物甚至分组事物都有可能放在一个包中。包纯粹是概念上的，只存在于开发阶段，而组件在运行时存在。④注释事物（Annotationalthings）注释事物是UML模型的解释部分。ZLL（2）关系关系是将事物联系在一起的方式，UML中定义了四种关系，每种关系还可以有不同的系统版型和自定义版型。①依赖（Dependencies）：两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物；②关联（Association）：一种描述一组对象之间连接的结构关系，如聚合关系（描述了整体和部分间的结构关系）；③泛化（Generalization）：一种“一般-特殊”的关系；④实现（Realization）：接口和实现接口的类之间的语义关系。接口指定了由“实现类”保证执行的操作。ZLL（3）图（Diagram）图是事物（Things）的集合，UML中包含多种图。①类图（ClassDiagram）：类图描述系统所包含的类、类的内部结构及类之间的关系；②对象图（ObjectDiagram）：对象图是类图的一个具体实例；③包图（PackageDiagram）：包图表明包及其之间的关系；④组件图（CompomentDiagram，也称组件图）：组件图描述代码部件的物理结构以及各部件之间的依赖关系；⑤部署图（DeploymentDiagram）：部署图定义系统中软硬件的物理体系结构；⑥用例图（UsecaseDiagram）：用例图从用户的角度出发描述系统的功能、需求，展示系统外部的各类角色与系统内部的各种用例之间的关系；⑦顺序图（SequenceDiagram，又称序列图）：顺序图表示对象之间动态合作的关系；⑧协作图（CollaborationDiagram）：协作图描述对象之间的协作关系；⑨状态图（StatechartDiagram）：状态图描述对象的所有可能的状态以及事件发生时状态的转移条件；⑩活动图（ActivityDiagram）：活动图描述系统中各种活动的执行顺序;ZLL2．通用机制（commonmechanisms）包括规格说明（specification）、修饰（adornments）、公共划分（commondivisions）、扩充机制（Extensibilitymechanisms），通用机制提高了UML的表达能力和扩展能力。UML模型至少包含两个维度——图形维度和文本维度。图形维度用图形来表达可视的模型，文本维度用于表达不同模型元素的规格说明。规格说明用文本来表达元素的内容。软件模型必须是完整的，以便于软件系统的建造。不同的模型要素其规范说明的内容不同，这些规范说明的内容一般用属性名和属性值的形式来表达。属性一般作为模型成分附加说明，比如，用一些文字逐条列举类的功能，这种规范说明方式是非形式化的。UML模型图中的要素通常都有一个基本的结构，它描述模型成分最主要的特征。当使用UML的基本元素难以有效地表达复杂事物时，就需要对UML进行某种形式的扩充。UML的扩充机制包括：版型（stereotype）、标记值（taggedvalue）和约束(constraint)。ZLL（1）版型（stereotype）（2）标记值①UML成员的标记值②类型、类对象、类操作和类特征的标记值③模型组件的标记值④自定义标记值（3）约束①对关联的约束②对关联角色的约束③对消息、链接角色和对象的约束④自定义约束（4）公共划分①类和对象。通常对象和类使用同样的要素。在对象的名字下面加下划线以示区别。②接口和实现。接口定义了一种协议，实现是此协议的可用版本。2．通用机制（commonmechanisms）ZLL3．架构(architecture)架构用于表达系统高层组成部分之间的关系。一个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体。系统架构通常用“4+1”视图（view）来描述。4个视图分别是逻辑视图（logicalview）、进程视图（processview）、实现视图（implementationview）和部署视图（deploymentview），1个视图指的是用例视图(usecaseview)。这里的视图不同于图，视图是用多种表达方式来表达系统的某一个侧面。ZLL3．架构(architecture)逻辑视图用于捕获问题域的概念和词汇作为面向对象系统中的类或者对象，逻辑视图注重描述如何用类和对象来完成系统所需要的行为；进程视图为包含线程或进程的类进行建模。在逻辑视图中创建进程视图可采用如下方法：通过在逻辑视图中创建一个“包”并将其命名为“ProcessView”，可以表示进程视图。在进程模型中使用“主动类”来表示进程；在进程视图中，UML将进程和线程表示为主动类。通过创建一个类并为其指定<process>或<thread>版型，可以在进程视图中创建一个主动类，可使用序列图表示进程和线程的生命周期，每一个进程或线程都应出现在创建和删除它的序列图中。实现视图包括用于组装物理系统的组件和文件，主要描述了系统版本的配置管理。系统版本是由独立的组件和文件构成的可运行系统。实现视的静态方面由组件图来描述，动态方面也由交互图、状态图和活动图来描述。部署视主要描述了物理系统组成部分的分布、交付和安装，部署视的静态方面由部署图来描述；动态方面也可由交互图、状态图和活动图来描述。用例视图可以描述可为用户、分析人员和测试人员所能看见和理解的系统行为，用例视的静态方面由用例图来描述。动态方面由交互图、状态图和活动图来描述。ZLL14.3业务建模——14.3.1业务模型概述

业务建模（BusinessModeling）是RUP核心工作流的一个可选过程。如果对客户的业务很了解而且业务风险(因为不了解或曲解业务带来的风险)也很小，则可以没有业务建模过程。但是适当的业务建模可以加深涉众（stakeholers，与项目相关的所有人）对业务的熟悉程度，降低业务风险。业务建模是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系。业务建模强调以体系的方式来理解、设计和架构企业信息系统。同时它仅仅用软件建模的方式为企业组织的各个元素进行建模，而不涉及到计算机系统的概念。业务模型是以组织之外视角来观察组织内部要素和过程的模型。业务建模是建模方法的集合，目的是对业务进行建模。这方面的工作可能包括了对业务流程建模，对业务组织建模，改进业务流程，领域（Domain）建模等方面。业务建模的主要目的是使组织外部能够清晰的了解组织内部的结构及运行机制；同时可以使组织内部能够了解当前存在的问题并确定改进的可能性；确保客户、最终用户和开发人员就目标组织达成共识，从而可以以业务模型导出支持目标组织所需的系统需求。为实现这些目标，业务建模工作流程说明了如何拟定新目标组织的前景（vision），并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色以及职责。一旦较准确的建立了组织的业务模型，就可以依此获得系统的主要需求，精确的业务模型可以很好的映射到系统的需求模型，而不会发生大的语义断层。在业务建模的过程中，经常用到的图是业务用例图和业务用例的实现-通常用活动图来表达，还有业务对象图。这些模型中的元素都可以很好的映射到需求模型中。ZLL14.3.2业务用例（businessusecase）模型

业务用例（简称BUC）模型描述一个业务的流程以及这些流程与外部各方（如客户和合作伙伴）之间的交互。在业务用例模型中的主要元素包括业务主角（businessactor）、业务工作者（businessworker）和业务用例（businessusecase）以及它们之间的关系。其图形表示如图14-16所示。ZLL（1）业务分包采用银行系统的标准分法，将所要描述的业务分成两个部分，资产业务和负债业务。如图14-17所示，将银行业务分成两个包，资产业务和负债业务。ZLL（2）分析业务主角（3）分析业务工作者（4）抽取业务用例ZLL14.3.3业务用例实现（businessusecaserealization）

业务用例本身展示了业务的外部视图，它确定了业务为了向主角交付期望结果所进行的活动，同时还确定了执行业务用例时，业务与主角之间需要进行哪些交互。必须在确定每个业务用例后才能制作该视图。这一系列业务用例描述了业务的概貌，对雇员了解执行业务的哪些不同部分以及所期望的结果十分有用。另一方面，业务用例实现给出了业务用例的内部视图，它确定了如何组织和执行工作来获得期望的结果。实现中包含了业务角色和业务实体，它们涉及业务用例的执行，以及进行该工作所需的业务角色和业务实体之间的关系。必须制作该视图，以便确定为了获得期望的结果，如何在每个业务用例中组织工作。在业务模型的演进过程中，已经用规范的业务用例模型对业务进行了划分和初步的精化，但并没有对业务用例具体的实现过程进行充分的表达，只是在业务用例文档中给了不规范的说明。业务用例的实现实际上就是表达业务工作者如何同业务实体相互作用来完成用例的。业务用例实现通常也被称为业务分析模型，因为该模型是在对业务描述和业务用例模型分析的基础上演进而来的模型。这里的业务实体代表业务角色处理或使用的“事物”（things）。比如储户（业务主角）提交给柜员（业务工作者）处理的储蓄存款单就是业务实体，贷款审批表同样是业务实体，因为它是贷款审查委员会和贷款审查岗要处理的事物。用例实现可以用对象图、交互图、活动图、类图等表达。建立业务用例实现的步骤：①用业务活动图表达业务用例的实现；②从业务实体中抽取业务对象模型。下面仅就银行的负债业务进行业务分析。ZLL（1）用业务活动图表达业务用例实现

在业务用例模型中，通过对业务用例文档的分析，将业务用例文档用活动图来表达，从而规范地描述了业务用例的实现过程。活动图又叫OO流程图。因为活动图是行为建模的重要手段，所以它可以在RUP的很多个阶段发挥作用。业务建模、分析、设计阶段都可以使用。但是在业务分析阶段用的最多，所以活动图在本书中归为分析阶段的一个产品。如图14-20所示，是银行信用放款业务用例的业务活动图。贷款申请审核提供相应资料审查资格审查风险评估资料存档评估贷款人信贷员银行负责人贷款调查贷款审查贷款审查委员会审批填写贷款审批表通过受理属实合格ZLL（2)从业务实体中抽取业务对象模型业务实体的图形元素如图14-21所示。图14-21业务实体申请书清单资料抵押物贷款审批表抵押物申请书清单资料贷款审批表贷款ZLL14.4需求——14.4.1需求建模概述

需求阶段主要活动是建立系统的用例模型，通过用例模型表达系统的功能需求，对于非功能需求，需以非规范化的方法用自然语言在补充规约中进行描述。需求开始于先启阶段的后期至精化阶段的前期。需求模型与业务模型之间的追踪关系ZLL14.4.2从业务模型到系统模型

在业务模型的基础上，根据客户对系统的要求，对业务模型进行进一步的分析和映射，从而得到系统需求模型和系统的分析模型。从系统的业务模型向系统的需求模型映射的过程中，并不是所有的业务需求都要转化成系统需求。可以按照如下步骤实现从业务模型到系统模型的映射：（1）获取系统需求（2）分析业务主角和业务工作者，提取系统主角（3）需求的用例描述（4）用例的精化和分包ZLL14.4.3获取系统需求

需求通常被分为功能需求和非功能需求。功能需求描述的是计算机系统应该具有的行为，有数据输入到系统和/或有数据从系统中流出的需求就是功能需求。比如“打印对账单”这样的需求就是功能需求，因为这个需求有数据输入——客户之间的资金往来，还有数据的输出——对账单。非功能需求描述了系统的属性和对系统的必要限制，“对账单生成的速度小于5秒”这样的需求就是非功能需求。需求是系统开发的基石。需求仅仅描述系统应该做什么，而不是如何去做。在收集需求的过程中，要记录需求。对于访谈中记录的需求UML并没有给出一个好的建议。在记录需求的过程中，建议用较规范的方法来记录需求。比如<id><system>shall<function>其中id是需求的标识，system是系统的名称，shall关键词function应该具有的功能。比如100011银行系统shall打印对帐单需求的记录也可以采用树状结构，来表达需求之间的层次关系。一旦获取了系统需求，就可以从业务模型向系统的需求模型映射，一定要清楚，并不是所有业务领域的模型都要映射成为系统需求模型，只映射系统需求所要求的那部分就可以了。ZLL14.4.4系统主角的提取在业务建模的过程中，已经抽取了业务工作者和业务主角，其中业务主角在组织之外且同组织有交互，而业务工作者在组织之内互相协作完成必要的业务过程。在业务建模阶段的业务工作者通常映射成系统需求模型中的角色。但并不是所有的业务工作者都成为系统需求模型中的角色。只有那些同计算机系统有交互的业务工作者才成为系统需求模型中的系统主角。对于业务主角来说，如果业务主角直接同计算机系统交互（比如客户通过自动取款机而不是银行的柜员进行交易），那它就成为系统的主角。ZLL14.4.5需求的用例描述系统主角提取之后，就应该提取系统的用例（SystemUseCase，SUC）。系统用例主要有三个来源。业务模型、需求描述、特性表。构造一个系统之前第一个要考虑的事情就是系统的边界（boundary）。也就是说，应该定义哪些属于待开发系统的内部，哪些属于系统的外部。主题表达了谁或是什么在使用该系统以及系统给这些主角带来的好处。主角是直接同系统交互的外部实体。主角的概念与角色的概念基本一致，角色通常是同职责相对应的。比如教师角色，他的职责就是教书育人。比如系统管理员，其职责就是保证系统安全正常的工作以及系统的日常管理。教师和系统管理员都是与一定职责相关联的角色。注意一个真正的人可以同时扮演多个角色，比如他既是系统管理员又是教师。抵押放款信用放款担保放款信贷员银行系统主题名系统边界ZLL对下列问题的回答有助于识别主角：（1）谁使用该系统？（2）在交互过程中他们充当了什么角色？（3）谁安装系统？（4）谁来启动和关闭系统？（5）谁来维护系统？（6）什么系统与该系统有交互作用？（7）谁向系统提供信息或是从系统获得信息？（8）有固定间隔的事件发生么？ZLL如果系统每隔固定的时间就有事件发生的话，定时器就可以作为一个主角来启动用例。比如，在银行系统中，由于凌晨的业务量很小，所以定时启动数据备份用例，如图14-28所示。定时器数据备份ZLL对下面问题的回答有助于识别用例：（1）指定的主角希望系统包含什么功能？（2）系统是否存储和检索数据，若有的话，是谁激发这个行为？（3）系统状态改变时发生了什么，是否有角色得到系统状态变化的通知（4）是否有外部事件影响系统，事件发生时系统得到什么样的通知？（5）系统是否与外系统有交互？（6）系统产生一些报告么？贷款人（from主角）抵押放款（from用例）信用放款（from用例）担保放款（from用例）

信贷员（from主角）ZLL14.4.6用例的精化创建了包含主角和关键用例的系统用例图后，就要对用例进行精化。精化包括对用例的细化和详细说明用例，即给出用例文档。用例的细化指用例的进一步细分。初步的系统用例经过细分后，可以更精确地描述系统的需求。也就是对用例图中较复杂的用例进行分解。例如，对于“信用放款”用例进行精化，可以将其分解成如图14-30所示的精化后的用例图。在分解用例的时候，应该充分地理解系统的需求描述，通过对系统的需求描述进行分析得到系统的细化的用例和用例图。如对系统中信用放款的叙述可以对信用放款进行分解。ZLL14.4.6用例的精化ZLL14.4.6用例的精化信用放款用例的形式化的用例文档用例：信用放款ID:001简单描述：贷款人以其信用进行贷款角色：贷款人前置条件：信用记录良好基本事件流：1.提交贷款申请2.检查贷款资料3.审核贷款资格和额度扩展点：无资格贷款4.银行法定代表人审批扩展点：拒签5.发放贷款后置条件：债权债务关系建立变换流：无ZLL14.5.1分析建模概述

分析开始于先启阶段的后期，并且成为精化阶段的主要任务。先启精化构建移交业务需求分析设计实现测试部署初始迭代I1I2I3InIn+1In+2ImIm+1ZLL建立系统行为模型是精化阶段的主要活动。需求和分析之间的界限并不十分明确，通常需求活动会伴随分析活动。也就是说需求和分析之间有重叠的部分。分析的主要任务是建立系统的分析模型。该模型主要表达系统应该完成的功能，功能的具体实现细节留给设计阶段。分析和设计的界限也较模糊。分析阶段的后期常常伴随着设计活动。分析模型与需求模型之间的追踪关系如图14-33所示。14.5.1分析建模概述<<trace>>需求模型分析模型ZLL14.5.2发现分析类分析类是问题领域的抽象，是现实世界业务概念的一个映射。分析类必须较严格地从真实世界的业务概念得来。因此，OO软件构造的第一步就是明确问题域，一旦问题域中的概念和概念之间的关系变得清晰而且简单，就得到了一个好的解决方案。分析类中不应包括任何应在设计（解决方案域，solutiondomain，与问题域相对应）时才考虑的那些类。比如为提高性能而采用的线程池（threadpool）类，以及连接数据库所用的连接类等。虽然在需求阶段识别的更多的是对象本身，这些对象在需求阶段并没有被抽象成类。而在分析阶段，关注更多的是类而不是对象。分析类中应包含“高层”属性，这些属性将成为设计类的候选属性。分析类的操作集合应该是类所提供的关键服务的集合。在设计阶段，这些操作成为真正的可实现的操作，并且一个服务可能被分解成多个操作。在分析阶段，UML类的语法只是部分被用于表达分析类。分析类中一定要避免出现与实现有关的细节，毕竟分析阶段关注更多的是系统整体的结构和元素，而不是结构和元素背后的实现细节。比如，在分析构造一台汽车的需求时，对于发动机来说，只关心它带来多大的动力，百公里油消，而具体发动机是几个缸的、用什么方式点火并不关心。因为这些是实现细节。ZLL分析类中通常包括如下内容：（1）分析类名，这是必须的。（2）属性，每个属性必须有属性名，属性的类型通常不关注，因为那是实现细节。比如学生的学号究竟是整型还是字符串型并不关注。（3）操作，类的职责或服务。在分析阶段，类的职责通常用公共方法或是接口来实现，体现了外部可操作的特性。只有在特别必要的情况下才标识操作的类型和操作的参数类型。（4）可见性，通常不需要标识。图14-34UML的类BankAcountaccountNumberownerbalancewithdraw()calculateInterest()deposite()（5）版型（sterotype），通常只在必要的情况下使用。（6）标记值（taggedvalue），通常只在需要的情况下使用。图14-34是一个简单的分析类的图形表达。图14-34UML的类BankAcountaccountNumberownerbalancewithdraw()calculateInterest()deposite()ZLL在抽象分析类时应注意以下几点：（1）分析类名确切，能准确地表达该类的意图；（2）分析类是问题域元素的抽象；（3）分析类是问题域特性的映射；（4）分析类有一个小的定义良好的职责的集合；（5）高内聚，低耦合。ZLL职责职责通常指合约（contract）或责任(obligation)。它代表一个类所能完成的任务。职责是一个类可以为其他类提供的服务。类的职责应该是根据业务类的真实情况以及该类的真实目的来分配。比如前面提到的购物车类，其职责应该为：（1）添加商品（2）移除商品（3）显示购物车中所有的商品这些职责都是关于维护购物车中商品的操作。因为所有的职责有一个统一的目标——维护购物车中的商品，所以这些职责是高内聚的。当然也可以把这些职责抽象成一个更好的职责——购物车维护。在购物车中也可能分派如下的职责（1）检查信用卡的真实性（2）收款（3）打印收据但是这些职责不符合购物车的本质语义。同时这些职责与购物车原本的职责根本没有内聚性可言，所以这些职责应该分派给其他分析类。比如，把检查信用卡的真实性这个职责分派给CardCompany类，把收款这个职责分配给Chekout类，把打印收据职责分配给ReceipPrinter类。恰当的分配职责可以增加分析类的内聚性。ZLL在抽象分析类的过程中应该注意，每个分析类大约3～5个职责为益。同时也不能过分追求低耦合。因为只有类之间协作才能完成用户的需求。如果在分析过程中发现许多小型的类（职责只有1、2个）争取采取策略合并成合适规模的类。少量的大类（职责超过5个）应该考虑分解该类成合适规模的类。混合型的大类（无所不包的类）也要进行分解。在分析过程中还要避免多层的继承关系。通常问题域中明显存在的继承关系才在分析模型中以继承的关系建立。而且层次最好不要超过3层。抽取分析类的方法很多，包括名词/动词（noun/verb）分析、类-职责-协作（class-responsibilities-collaborators，CRC）分析、RUP版型分析等。其中名词/动词分析是从需求模型和相关描述得到分析类及其属性和方法。名词和名词短语通常识别为分析类或分析类的属性，动词则为分析类的职责。CRC是一种由专家经过集体讨论方法产生系统的分析类。前两种方法主观性较大，不利于从需求模型到分析模型的准确映射。下面说明如何用RUP版型来得到分析类。RUP中抽取分析类的核心思想就是把分析类分成三种版型，边界类(boundaryclass)、控制类(controlclass)和实体类(entityclass)，三种分析类是用不同的版型来区分的，如图14-35所示。其中的LoanUI是边界类，Loan（贷款）是控制类，BankHeader是实体类。LoanUILoanBankHeader

图14-35RUP三种分析类抽象LoanUILoanBankHeaderZLL边界类边界类存在于系统的边界并与系统外的用户进行交互，在主体和其环境之间很容易发现边界类。边界类有三种类型。（1）用户接口类—用于实现人机接口的类（2）系统接口类—用于实现与其他系统接口的类（3）设备接口类—用于实现与外部设备接口的类ZLL控制类控制类用于协调系统中的一个或多个用例，使其按照正常的流程进行。控制类的发现主要考虑系统的用例如何通过分析类的协作来完成的。简单的控制行为可以直接分布到边界类和/或实体类中，而不需要再用单独的控制类来协调。比如合同管理系统中的“修改合同”用例，其修改流程因为简单可以放到ContractModifyInterface边界类中进行处理，没必要单独抽象控制类对合同的修改流程进行控制。但是对于“合同变更”、“订单处理”等这样具有较复杂流程的用例，应该单独抽象控制类来控制用例的流程，比如可以用ContractManager来控制合同的执行流程，用OrderController来完成订单的流程控制。通常用Manager或是Controller作为控制类类名的后缀，以便明确地说明该类是个控制类。发现控制类的关键是控制类应该真正来自问题域而不是主观想象。有些建模者为每个用例都配备了一个控制类来控制用例内部的执行流程，这是典型的面向过程的自顶向下的功能分解而非面向对象的分析。真正的控制类几乎都来自问题域，比如选课系统中的登记员（registra）类。如果发现一个控制类的行为过于复杂，就要把这个控制分成几个简单的类，这些简单的类也应该来自问题域。比如，对于一个选课系统来说，可能会抽象出CourseRegistrationController用于控制整个选课过程。但是由于这个类的行为过于复杂，要对其进行适当的分解，分解后的控制类应该相互协作完成CourseRegistrationController的职责。CourseRegistrationController可分解为Registra、CourseManager和PersonnelManager三个类，而这三个类也在问题域内。ZLL实体类实体类可来自业务实体，也就是说业务模型中所有的业务实体都可以映射到分析模型的实体类上，比如银行业务模型中的贷款申请书，就是分析模型中的实体类。实体类通常只有简单的set/get方法，同时需要持久化支持。实体类通常会跨越多个用例，即一个实体类可为多个用