需求分析与系统设计2.ppt

《需求分析与系统设计2.ppt》由会员分享，可在线阅读，更多相关《需求分析与系统设计2.ppt（236页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、需求分析与系统设计需求分析与系统设计 第二章第二章 需求分析基础需求分析基础 面向对象的开发要求对对象技术有很好的理解。没有对对象技术深层次的理解，开发人员就不能正确地使用UML作为惟一且贯穿全过程的建模语言。学习面向对象技术是一种“从中间出发”的方法。不管我们如何加快学习的进程，我们总是处于学习过程的中间阶段（由于新的问题总在出现）。当读者理解了在面向对象系统中“任何东西都是对象”这个事实的深刻含义后，才算是通过了成功学习的第一阶段。第二章第二章 需求分析基础需求分析基础 l2.1对象技术基础 l2.2分析建模中的学习指导 l2.3案例分析的问题陈述 2.1对象技术基础 解释信息系统中面向对

2、象概念的一个好的方法是提供与具体的实际生活中对象的一个类比。l我们周围的世界由一个个处于特定状态的对象组成，对象的状态由该对象当前的属性值来确定。l一些实际生活中的对象具有行为。l所有现实生活中的对象还有身份，这一个固定的特性，通过它我们可以将一个对象从别的对象中识别出来。具备三个特性（状态、行为、身份）的现实生活对象构筑自然行为系统。2.1对象技术基础l2.1.1实例对象 l2.1.2类 l2.1.3关联 l2.1.4聚合和组合 l2.1.5泛化 l2.1.6类对象 2.1.1实例对象 l对象是“东西”的实例，它可以是同一个“东西”的多个实例中的一个。l一件“东西”的通用描述称为一个类，因此

3、，对象是类的实例。l但是，类本身也可能需要实例化，它可以是对象。由于这个原因，我们需要区别实例对象和类对象。2.1.1实例对象l2.1.1.1对象表示法 l2.1.1.2对象如何协作 l2.1.1.3对象如何相互识别 2.1.1.1对象表示法 lUML的对象表示法是含两个格的长方形，上面的格子包含对象的名字和该对象所属类的名字。其语法为：objectname:classname l下面的格子包含属性名和属性值的一个列表。属性的类型可以用下面的语法形式给出：attributename:type:=value 2.1.1.1对象表示法 图2-l给出了一个名为c1的Course对象，这个对象有两个属

4、性，这个属性的类型没有说明它们已经在类的定义中声明了。重要的是，要注意对象表示法没有提供罗列实例对象可以执行的操作的格子，这是因为操作对所有实例对象是相同的，要是在每个实例对象中都重复存储会带来冗余。操作可以用其他方式存储在与实例对象关联的类对象中（在基本面向对象系统软件中实现）。2.1.1.1对象表示法 2.1.1.2对象如何协作 l特定类的对象的数目可以非常大。在一个图中显示许多对象是不现实的，也是不可行的。画出对象只是为了示例某个时间点上的系统，或者示例它们如何协作来完成某项任务。l系统任务由相互调用各自的操作（行为）的一组对象来完成。我们称它们在交换消息。消息触发了对象上的操作，而操作

5、可以导致对象状态的改变并调用其他的操作。2.1.1.2对象如何协作 图2-2给出了四个对象之间的消息流。消息名之后的括号表明消息可以带有参数（就像在传统程序设计中的函数调用一样）。对象Order请求对象Shipment装运所订购的货物，为了实现请求，Shipment命令对象Stock从产品库存量中减去适当的数量，然后对象Stock分析新的存货量，如果库存量很低，它请求对象Purchase再订购更多的这种产品。2.1.1.2对象如何协作2.1.1.2对象如何协作 虽然我们将上述对象协作解释为一个活动序列，我们甚至为消息编了号，但通常消息流并不将严格的时序强加在对象的活动上。例如，analyzeS

6、tockLevers或 reorderProducts可以按任意的）顺序执行，可能还独立于 shipOrder和 subtractProduct。由于这个原因，我们在设计级讨论对象的协作时将放弃给消息编号。2.1.1.3对象如何相互识别 一个对象怎么知道它想要发送信息的另一个对象的身份？每个对象在创建时都被赋予一个对象标识符（OID），OID是对象的句柄，它是惟一个在对象的整个生命期中都保留的编号。如果对象X想要发送一条消息给对象Y，那么X必须知道Y的OID。建立对象间的OID 链接有两个实际的方案 l永久OID链接。l临时OID链接。2.1.1.3对象如何相互识别 这两种OID链接之间的区分

7、必须与对象的生命期一起考虑，一些对象只在程序执行期间才是活动的，它们由程序创建并在程序执行期间或程序终止执行时消失。这些是临时对象。其他一些对象比程序的执行更长寿，它们在程序终止时存储在永久磁盘存储器中，并且在程序的下一次执行中仍然有用。这些是永久对象。2.1.1.3对象如何相互识别l2.1.1.3.1永久链接l2.1.1.3.2临时链接2.1.1.3.1永久链接 永久链接是永久存储中的一个对象链接到永久存储中的另一个对象（或一组其他对象）的一个对象关联（或一组对象关联）。因此，为了将一个Course对象永久地链接到它的Teacher对象上，对象Course必须包含一个链接属性，该属性的值为对

8、象Teacher的OID，这个链接是永久的，因为这个OID被物理地存储在对象Course中，如图2-3所示。2.1.1.3.1永久链接2.1.1.3.1永久链接 对象c1的OID在这里被标记为Ref&*)(，这个对象包含一个名为teacher的链接属性，这个属性的类型是identtity，它的值是一个奇怪的数Ref#$%，表示对象Teacher被永久存储的磁盘地址。一旦对象Course和对象Teacher被调进内存，Teacher属性的值将被掺合成内存指针，从而建立对象间的内存级协作（掺合并不是UML的术语它用在对象数据库中，在那里，对象在永久存储器和临时内存之间的调进调出是很频繁的）。2.1

9、.1.3.1永久链接 图2-3示例了一般情况下如何实现永久链接。然而，在UML建模过程中，对象之间的链接被画成如图 24所示形式，这些链接表示成对象Course和 Teacher关联的实例。2.1.1.3.1永久链接2.1.1.3.1永久链接 通常，协作链接支持双向导航。每个Course对象链接到它的Teacher对象，并且每个Teacher对象可以通向Course对象。当然虽然不太经常只允许一个方向的导航也是可能的。一旦一个对象永久地链接到另一个对象，它可以顺着该链接发送消息请求另一个对象的服务，这就是说，一个对象能够通过发送消息给另一个对象来调用它上面的操作。通常的情景是，为了指向一个对象

10、，消息发送者将使用程序的变量来包含那个对象的链接值（OID值）。2.1.1.3.1永久链接 例如，由对象Teacher所发送的用来发现对象Course的一个消息可以成为如下形式：crs.ref.getCourseName（out crs_name）在这个例子中，特定的将用来执行getCourseName的类Course的对象被链接变量crs.ref的当前值所指向，输出（out）参量crsName是要用在类Course中实现的操作getCourseName返回的值初始化的变量。2.1.1.3.2临时链接 如果我们没有定义Course和Teacher之间的永久链接，但是我们还需要由对象t1发送一个

11、消息到对象c1来调用操作getCourseName，结果将会怎样呢？应用程序必须有其他方式来找出对象c1的身份，并且创建从对象t1到对象c1的临时链接。2.1.1.3.2临时链接 有许多技术通过内存来驻留对象c1的OID并对变量crs.ref进行初始化。l对老师（Teacher）的t1有效性以及课程（Course）的时间表执行了一次搜索操作，已经确定老师t1应该教课程c1。l程序已经访问了将课程编号映射到老师编号的永久存储表，然后可以对Course对象进行搜索，以找到所有由老师t1所教的课程，并且请求用户确定消息getCourseName将要发给的课程。l在将它们存放到数据库中去之前先创建课程

12、和老师。在老师和课程之间没有永久链接，但是用户要输入信息使得每个课程清楚地标识一个负责的老师。这个程序然后可以将这个临时链接存放在程序变量（如crs_ref）中，而且这些变量以后可以被用来（在同一次程序执行期间）在 Teacher和 Course对象之间发送消息。2.1.1.3.2临时链接 简而言之，存在程序的和用户驱动的技术，为类之间还没有通过关联永久链接起来的对象之间建立临时链接。临时链接包含当前在程序内存中的对象OID值的程序变量。临时和永久OID间的映射（掺合）应该是基本程序设计环境的责任，如对象数据库系统。2.1.2类 类是一组具有同样的属性和操作的对象的描述器，它作为对象创建的模板

13、。每个按该模板创建的对象，包含与该类定义的属性类型一致的属性值，每个对象可以调用在它的类中定义的操作。2.1.2类 在图形表示上，类表示为带有三个用横线隔开的长方形的格子，如图2-5所示。顶上的格子保存类名，中间的格子声明类的属性，下面的格子包含操作的定义。2.1.2类l2.1.2.1属性 l2.1.2.2操作 2.1.2.1属性 属性是一个类型值的对，类定义属性类型，对象包含属性值，图26示例了两个带属性名和定义的属性类型的类。属件类型可以是内部原始类型，也可以是另一个类。原始类型为可直接理解的类型，并由基础面向对象软件环境所支持。图26中的所有属性类型都指派为原始类型。2.1.2.1属性l

14、2.1.2.1.1指派为类的属性类型l2.1.2.1.2属性可见性2.1.2.1.1指派为类的属性类型 一个属性类型也可以指派为一个类，在某类的特定对象中，这样的一个属性包含一个对象标识符（OID）值，这个值指向另一个类的一个对象。在UML分析模型中，属于基于类的类型的（不是原始类型）属性不出现在类的中间格子中，改为用类之间的关联来表示。图2-7显示了这样的两个类之间的关联。2.1.2.1.1指派为类的属性类型 关联线上的两个名字（the_shipment和 the_order）表示角色名，角色名标识本关联端点的含义，并用于建立映射到关联中另一个类的一个对象的导航。2.1.2.1.1指派为类的

15、属性类型 在所实现的系统中，角色名（这个关联的另一个端点）成为一个类属性，它的类型为由该角色名指向的类。图2-8显示了来自图2-7的两个类在它们将要被最终实现时的情景。2.1.2.1.2属性可见性 对象通过相互发送消息来协作。一个消息调用一个类操作。这个操作通过存取它自己对象中的属性值为调用对象的请求提供服务。一个可能的情景是，这个操作必须对外面的对象是可见的（消息必须看得见操作），这样的操作被称为具有公共可见性。2.1.2.1.2属性可见性 在纯面向对象系统中（就像Smalltalk程序设计环境所示例的那样），大多数的操作都是公共的，但大多数的属性都是私有的，属性值对其他的类是隐藏的。一个类

16、的对象只能请求另一个类在公共界面上发布的服务（操作），它们不允许直接操作其他对象的属性。2.1.2.1.2属性可见性 操作封装了属性。然而必须注意，封装只作用到类。一个对象不能对相同类的另一个对象隐藏（封装）任何东西。可见性通常用加号或减号来指派：l+指公共可见性l-指私有可见性 这些符号在某些 CASE工具被替换为图标。图 2-9显示了表示属性可见性的两个图形表示。2.1.2.1.2属性可见性2.1.2.2操作 对象包含数据（属性）以及作用于这些数据的算法（操作）。操作在类中声明。实现这个操作的过程称为方法。操作（或更精确地说是方法）由发送给它的消息所调用。消息名和操作的名字是相同的。操作可

17、以包含一列参数，这些参数可以在消息调用时设置为特定的值，操作可以给调用的对象返回一个值。操作名与一列形式参数的名字合在一起称为操作的型构，型构在类中必须惟一，这意味着一个类可以有多个相同名字的操作，但它们的参数类型的列表不同。2.1.2.2操作l2.1.2.2.1操作支持对象协作l2.1.2.2.2操作可见性和范围2.1.2.2.1操作支持对象协作 面向对象程序通过响应来自于用户的随机事件来执行，这些事件来自键盘、鼠标、菜单。活动按钮以及任何其他输入设备。用户产生的事件转换为发送给对象的消息。为了实现一个任务，许多对象需要协作，它们通过调用其他对象中的操作来协作。2.1.2.2.1操作支持对象

18、协作 图2-10展示了支持图2-2中的对象协作所必须的类操作，图2-2中的每个消息都要求由消息目的地指派的类中的操作，在这个例子中，类Order没有任何操作，类Order的一个对象启动了这个协作，这个Order对象请求一个Shipment对象为它运送货物，作为货物运送的结果，库存需要新的产品来补充。2.1.2.2.1操作支持对象协作2.1.2.2.2操作可见性和范围 操作可见性原理与属性可见性并没有什么不同，操作可见性定义该操作在不同于该类的其他类的对象中是否可见。如果是可见的，则该操作的可见性为公共的，否则是私有的。图2-10中操作名之前的图标表示了公共可见性。2.1.2.2.2操作可见性和

19、范围 面向对象系统中的大多数操作具有公共可见性，对于为外界提供服务的对象来说，“服务”操作必须是可见的。然而，大多数对象也有许多内部管理操作，这些操作被赋予私有可见性。它们只在它们被定义的类中是可存取的。2.1.2.2.2操作可见性和范围 操作可见性需要与操作范围区别开来。操作可以在一个实例对象中被调用，或者它还可以在一个类对象中被调用。对前一种情况，操作被说成是具有实例范围，而后一种情况则具有类范围。例如，寻找雇员的年龄的操作具有实例范围，但计算雇员的平均年龄的操作就具有类范围。2.1.3关联 关联是类之间的一种关系，类之间的其他关系还包括泛化、聚合、依赖和其他更多一些。关联关系提供给定类的

20、对象之间的一个链接，需要相互通信的对象可以使用这种链接。对象之间的消息一般是沿着关联关系发送的。图2-11展示了类Order和 Shipment之间的名为 Ordship的关系，这个关系支持一个Order对象被运送（被链接）到多于一个Shipment对象（由星号*指明），而且一个Shipment对象能够运载（链接）多于一个Order对象。2.1.3关联2.1.3关联 l2.1.3.1关联度 l2.1.3.2关联多重性 l2.1.3.3关联链和程度 l2.1.3.4关联类 2.1.3.1关联度 关联度定义被这个关联连接起来的类的数目，最常见的关联为二度关联，这种关联称为二元关联。图2-11中的关

21、联是二元的。关联还可以只定义在一个类上，这称为一元（或单元）关联，一元关联建立单个类的对象之间的链接。虽然一般不建议这样，但三度关联（三元关联）也是可能的。2.1.3.1关联度 图2-12是一元关联具有代表性的例子，它捕获了雇佣的层次结构，一个Employee对象被另一个Employee对象所控制（managed_by），或不被任何人控制（即他是首席执行官（CEO），不被任何人控制），一个Employee对象是许多Employee对象的控制者（manager_of），除非他是雇佣梯队中最底层的雇员，那样他不控制任何人。2.1.3.1关联度 2.1.3.2关联多重性 l关联多重性定义多少对象可以

22、填充由角色名标识的位置，多重性指出多个目标类的对象（由角色名所指向的）可以与源类的单个对象关联。2.1.3.2关联多重性 多重性表示为一个整数范围nl.n2，整数nl定义所连接的最少对象的数目，而n2则为最多对象数（如果不知道确切的最大数的话，最大数可以用星号*表示）。如果不想指明最小数，但知道它可以被连接到多个对象，那根本就不指明最小数（如图2-11所示）。2.1.3.2关联多重性 最常见的多重性是：l0.1 l0.*l1.1l1.*2.1.3.2关联多重性 图2-13给出了类Teacher和 Courseoffering之间的两个关联。一个关联表示对当前排出课程的老师的安排，另一个关联确定

23、哪位老师负责哪门课程。一个老师可以教多门课或不教课（例如如果老师休假的话），一位或多位老师可以教一门课，由其中的一位老师负责这门课。通常，一位老师可以负责多门课或不负责任何课，一位且仅有一位老师管理课程安排。2.1.3.2关联多重性2.1.3.2关联多重性 关联多重性在UML中是一个含有过多含义的术语，“0”和“l”的最小多重性可以看成具有特殊语义的表示，称为成员关系或参与关系。“0”的最小多重性表示一个对象在一个关联中可选的成员关系，“l”的多重性表示强制的成员关系。例如，CourseOffering对象必须由一个Teacher对象所管理。2.1.3.2关联多重性 成员关系特性自身具有一些有

24、趣的语义。例如，特定的强制成员关系可以另外蕴涵该成员关系是固定的，即一旦对象链接到该关联的目标对象，它就不能再链接到同一个关联的另一个目标对象。2.1.3.3关联链和程度 关联链是关联的一个实例，它是一个对象引用的元组，这个元组是引用的集合或引用的表（有序集合）。通常，元组可以只包含一个引用。像以前讨论的那样，这个键也表示角色名。程度是链的集合。2.1.3.3关联链和程度 图2-14是图2-11中关联Ordship的一个特定实例，图2-14中有五条链，因此关联的程度是五。2.1.3.4关联类 关联经常有它自己的属性（和或操作），这样的关联必须用类来建模（因为属性只能在类中定义），关联类的每个对

25、象都具有属性值和对所关联的类的对象的链接。因为关联类是一个类，在通常情况下，它可以被关联到模型中的其他类。2.1.3.4关联类 图 2-15 示例了关联类Assessment，类Assessment的一个对象存储着ClassOffering中一个Student的分数表、总分和等级。2.1.3.4关联类 属性 mark的类型为 List（Number），它称为参数化类型，Number是类 List的参数，这里List定义一个值的有序集合，就是说，属性mark包含了在一门课程中学生得到的所有分数的表。就是说，如果学生“Fred”上了课程“COMR227”，总有他关于这门课的一个分数表（一个有序集）

26、，这个分数表将存储在一个Assessment对象中，这个对象表示“Fred”和“COMP227”间的关联。2.1.4聚合和组合 聚合是表示构件集合的类（超集类）和表示构件的类（子集类）之间的全体一部分关系，一个超集类包含一个子集类（或一组类）。这个包含特性可以是强的（值聚合）或弱的（引用聚合），在UML中，值聚合称为组合，而引用聚合简称为聚合。2.1.4聚合和组合 从系统建模的观点来看，聚合是一种特殊的并含有其他语义的关联。特别地，聚合是传递和反对称的。传递性指如果A包含B并且B包含C，则A包含C。反对称性指如果A包含B，则B不能包含A。2.1.4聚合和组合 组合有另外一个存在依赖特性，一个子

27、集类的对象不能在没有被链接到其超类对象的情况下存在，这意味着如果一个超集对象被删除（破坏），则它的子集对象也必须被删除。组合用“装饰”在链接到超类的关联线上的实心菱形表示，聚合（不是组合）则用空心菱形标记。然而要注意，如果建模者还不想对这个聚合是不是组协作出决定时，也可以使用空心菱形。2.1.4聚合和组合 图2-16左边给出了一个组合，而右边是一个一般的聚合，任何Book对象都是Chapter对象的一个组合，而任何Chapter又是Section对象的一个组合，一个Chapter对象没有独立的生命，它只在Book对象中存在。但BeerBottle对象就不是这样，BeerBottle对象可以在它

28、的包容器Crate对象之外存在。2.1.4聚合和组合2.1.5泛化 泛化是较通用的类（超类或父母）和较具体的类（子类或孩子）之间的一种关系，子类是超类的一个种类，子类的一个对象可以在超类被允许的任何地方使用。2.1.5泛化 泛化使得重新陈述已经定义的特性变得不必要了，为超类定义的属性和操作可以在子类中复用，子类被称为继承了它的父类的属性和方法，泛化支持增量式的规格说明、类之间公共属性的开发以及变化的更好的局部化。2.1.5泛化 泛化被画成连接到父类上的连线端点上的一个空三角形。在图 2-17中，Person是超类，而 Employee是子类，类Employee继承了类Person的所有属性和操

29、作。这些所继承到的特性不在子类的框中显式地表示出来，泛化关系强调后端的继承。2.1.5泛化 注意，继承作用到类上而不是对象上，而且它作用到类型上而不是值上。类Employee继承了属性full_name和date of birth的定义，类Employee的对象以后可以用一些值来实例化这些属性（由于在Employee对象中这些属性是与四个其他的属性date_hired、salary、leave_entitlement和leave_taken一同存在的）。2.1.5泛化2.1.5泛化l2.1.5.1多态性 l2.1.5.2 继承 l2.1.5.3抽象类 2.1.5.1多态性 被子类继承的方法经常

30、如同子类中的方法一样被使用。操作age（）对类Person和Employee的对象是起同样作用的。然而，有时操作在子类中需要被重载（修改），相当于子类的语义变化。2.1.5.1多态性 例如，Employee.remainingLeave（）用从leave_entitlement中减去leave_taken来计算（图2-17中），然而，作为经理的雇员还要获得一份年度的leave_supplement，如果我们增加一个类Manager到这个泛化层次中的话（如图2-18所示），则操作Manage.remainingLeave（）将重载操作 Eaployee.remainingLeave（），这在图

31、2-18中通过在子类中重写这个操作名来指明。2.1.5.1多态性2.1.5.1多态性 操作remainingLeave（）己经被重载，这个操作有两种实现（两个方法），我们现在可以发送一个消息 remainingLeave（）给一个Employee对象和一个Manager对象，我们将得到不同的运行方法，我们甚至可能不用知道或不用关心哪个对象作为目标，Employee或Manager，合适的方法总会被执行，操作 remainingLeave（）是多态的。2.1.5.2 继承 多态性只局限于没有继承时的使用情况，继承还允许子类通过复用来增量式地描述子类并扩展子类的描述。操作 Manager.rema

32、iningLeave（）可能通过调用 Employee.remainingLeave（）的功能，然后在Employee.remainingLeave（）的返回值上增加leave_supplement的值来实现。继承层次上的多个类可以声明同一个操作，这样的操作具有多种实现（方法），但用相同的型构名字、参数的数目和类型（如果有的话），多态的行为依赖于继承。2.1.5.2 继承 l2.1.5.2.1多重继承 l2.1.5.2.2多重分类 l2.1.5.2.3动态分类 2.1.5.2.1多重继承 一个子类可以继承多个超类。多重继承会产生继承冲突，这必须由程序员来解决。在图2-19中，类Tutor继承类

33、Teacher和Postgraduatestudent.Teacher，并转而继承 Person，PostgraduateStudent也继承（通过 Student）Person，结果 Tutor就继承了两次Person的属性和操作，除非程序员通过使用左继承路径或右继承路径来设置程序设计环境使其只继承一次（或者除非程序设计环境强制一些默认行为（对程序员来说可接受的）来删除多重继承）。2.1.5.2.2多重分类 目前，大多数的面向对象程序设计环境中，一个对象只能属于一个类。这是一个麻烦的限制，因为在实际情况中对象可以属于多个类。多重分类不同于多重继承。在多重分类中，一个对象同时是两个或更多类的实

34、例；而在多重继承中，类有许多超类，但对每个对象必须指定其所属的单个类。2.1.5.2.1多重继承 2.1.5.2.2多重分类 如图2-19所示的多重继承的例子中，每个Person对象（如Mary或Peter）属于单个类（作用于它的最具体的类），如果 Mary是一个 Postgraduatestudent，但不是一个 Tutor，则Mary的类就是 Postoraduatestudent。如果Person被说明为处于一个稍稍有些正交的层次中，问题就出现了。例如，一个Person可以是Employee或Student、可以是Male或Female、也可以是Child或Adult等等。没有多重分类，

35、我们就需要为每种合法的组合定义类。例如在上述正交层次中，需要为一个女性未成年学生的Person对象定义一个类（即可以称为ChildFemaleStudent的类）。2.1.5.2.3动态分类 目前，大多数面向对象程序设计环境中，对象在它被实例化（创建）之后不能改变它的类。这又是一个麻烦的限制，因为在实际情况中，对象需要动态地改变它的类。动态分类是多重分类直接的后果，对象不仅可以属于多个类，而且在其生命周期中可以获得或失去它的类。2.1.5.2.3动态分类 在动态分类的框架下，Person对象可以在某天只是雇员而在另一天成为经理（和雇员）。没有动态分类，像雇员提升这样的业务情况变化就很难（甚至不

36、可能）在类图中描述性地建模，它们将只能在状态图或相似的建模技术中过程性地建模。2.1.5.3抽象类 抽象类是一个重要的建模概念，它从继承的表示法向下展开，抽象类是一个没有直接实例对象的父类，只有抽象父类的子类才能被实例化。在典型的场景中，一个类是抽象的是因为它至少有一个操作是抽象的。抽象操作有被定义在抽象父类中的型构（名字和形式参数的表），但这个操作（方法）的实现却留给具体的子类去定义。2.1.5.3抽象类 抽象类不能实例化对象的原因是因为它至少有一个抽象操作，如果我们允许抽象类创建对象，那么给这个对象的抽象操作的消息就会引起运行时错误（因为在这个对象的类中就没有这个抽象操作的实现）。2.1.

37、5.3抽象类 如果一个类是被完全划分为子类的超类时，那它只能是抽象的。如果其子类包含了所有可能的可以在这个继承层次上实例化的对象，这个划分就是完全的。没有“丢失的”对象。图2-19中的类Person不是抽象的，因为我们可能想要实例化既不是老师也不是学生的Person对象。我们将来想要为 Person增加更多的子类（如 AdminEmployee）是可能的。2.1.5.3抽象类 图2-20显示了一个抽象类Video（在UML中，抽象类的名字用斜体显示），这个类包含抽象操作 rental Charge（），可以理解，对录像带和光碟，租金计算是不同的，所以将有两个不同的 rentalCharge（）

38、实现：在类VideoTape和VideoDisk中。抽象类不会有对象，但是它们在建模中是非常有用的，它们创建了一个高级建模“词汇”，没有它，建模语言就是有缺陷的。2.1.5.3抽象类2.1.6类对象 前面，我们说明了实例对象和类对象的区别，类对象是一个带有类范围属性和或类范围操作的对象，这里类范围蕴涵了作用到类本身的，而不是作用到任何实例对象上的全局属性或操作。2.1.6类对象 由于在纯面向对象系统中，存储是在对象中提供的，我们需要一个类对象来存储全局属性和操作。最常见的类范围属性是保存默认值或聚合值（如总计、数目、平均值）的属性，最常见的类范围操作是创建和消除实例对象的操作以及计算聚合值的操

39、作。2.1.6类对象 图2-21显示了一个含有类范围属性（max_courses_per_semester）和类范围操作（average StudentAge（）的类Student，每个学生每学期有相同的允许选择的课程数目，因而这个数应该存储在类对象中，计算学生平均年龄的操作具有全局范围，因为它需要访问（在Student实例对象中）单个的学生年龄，以便能够计算所有学生的平均年龄。2.1.6类对象 UML建议在类的长方形中对类范围属性和操作画上下横线。在图2-21中，属性名前的“$”符号声明一个类范围（或静态）属性。UML带有在中名为global的构造型表示法已经用于指明类范围（或静态）操作。2

40、.1.6类对象2.2分析建模中的学习指导 本节用一个简单的例子给出UML中可视化建模的快速学习指导，目的是展示各种UML图，并且显示它们如何配合在一起。每个UML图强调一个特定的系统视图，为了从整体上理解这个系统，必须开发和集成表示不同视图的多种UML图。2.2分析建模中的学习指导 l在最通用的层次上，我们可以区别三种UML模型，每种都有它自己的图和相关构造元素的集合：l1.状态模型 l2.行为模型 l3.状态变化模型 1.状态模型 表示系统的静态视图，它为数据需求建模。状态模型表示数据结构和它们的关系，静态建模的主要可视化技术是类图。2.行为模型 表示系统的操作视图，它为功能需求建模。行为模

41、型表示在数据之上的业务事务、操作和算法，有几种可视化技术用于行为建模：用例图、序列图、协作图和活动图。3.状态变化模型 表示系统的动态视图，它为对象随时间的进化建模。状态变化模型表示对象状态可能的变化（这里状态由对象属性的当前值以及和其他对象的关联来定义），状态变化建模的主要可视化技术是状态图。2.2分析建模中的学习指导 l2.2.1在线购物 l2.2.2用例建模 l2.2.3活动建模 l2.2.4类建模 l2.2.5交互建模 l2.2.6状态图建模 2.2.1在线购物 因特网已经革新了我们运作业务的方式，为了维持竞争力，组织不得不存在于因特网上，并扩展它们的业务应用以包括电子商务，这个变化是

42、应用前端的延伸，但是基本后端数据库仍然需要进行常规的业务事务处理。我们的快速学习指导涉及在线购物应用，我们考虑应用的后端接受客户的在线定单、定单的处理和填写、开发票以及货物运送至客户。2.2.1在线购物 这个学习指导设法达到展示UML可视化建模方法的目的，给出的建模活动的次序也设法显示出UML各种图之间的相关性。活动的次序可以不解释为建议的过程。实际上，这个过程是迭代增量式的，在这个学习指导中对用例建模的过于信任并不是软件开发实践的真实反映，类建模一般与用例建模同时进行。学习指导陈述：在线购物(客户定单处理)一个计算机制造厂商提供了通过因特网购买计算机的可能性，客户可以在制造厂商的Web页面上

43、选择一台计算机，计算机分为服务器、台式机和笔记本。客户可以选择标准配置，或者可以在线建立自己希望的配置。可配置的构件（如内存）显示在一个可供选择的表中。对每个新的配置，系统可以计算价格。要发出定单，客户必须填上运送和付款信息，可接收的付款方式为信用卡和支票；一旦定单被输入，系统向客户发送一个确认 email消息，并附上定单的细节，在等待计算机送到的时候，客户可以在任何时候在线查到定单的状态。后端定单处理包含下面所需的步骤：验证客户的信任度和付款方式、向仓库请求所订购的配置、打印发票并且请求仓库将计算机运送给客户。2.2.2用例建模 系统行为是当系统响应外部事件时所做的事情。在UML中，从外表上

44、可见并可测的系统行为在用例中捕获，一个用例执行一个业务功能，该功能对参与者来说是外表上可见的，并且在以后开发过程中可以被独立地测试。2.2.2用例建模 参与者表示与用例交互的任何人或任何事情（人、机器等），参与者与用例交互期望得到有用的结果。用例图是一个参与者和用例以及另外的定义和说明的可视化表示，用例图不仅仅是一个图，而是系统想要的行为的全文档化模型。同样的理解适用于其他UML图，除非特别说明，UML图的意思与UML模型是同义的。2.2.2用例建模l2.2.2.1参与者 l2.2.2.2用例 l2.2.2.3用例图 l2.2.2.4为用例编写文档 2.2.2.1参与者 参与者和用例从功能需求

45、的分析中就确定了，功能需求具体化为用例，用例通过给参与者提供某个值的结果来满足功能需求。业务分析员是选择首先标识参与者然后再标识用例或者反之并不重要。在本学习指导中，我们选择首先标识参与者。参与者的典型图形表示为“木棍人”（见下面），通常，参与者可以被显示为类长方形符号，跟一般的类一样，参与者可以拥有属性和操作（它发送或接收的事件）。分析学习指导：第1步（在线购物）参照上述学习指导陈述并考虑如下扩展的需求来发现在线购物应用中的参与者。ll.客户查看标准配置。l2.客户选择查看配置的细节。l3.客户选择在线订购计算机。l4.客户填写在线表格。l5.销售人员发送电子请求给仓库。l6.事务的细节em

46、ail给客户。l7.仓库获得发票并给客户运送计算机。l.客户查看标准配置。客户使用制造厂商的Web页面来查看所选择的服务器、台式机或笔记本的标准配置，价钱也同时显示出来。2.客户选择查看配置的细节 客户选择查看配置的细节，也许带有买它的意愿或建立一个更合适的配置。每种配置的价格在客户要求的情况下可以计算出来。3.客户选择在线订购计算机 客户可以选择在线订购计算机，或者也可以要求销售人员在定单真正发出之前与自己联系，解释定单的细节、协商价格等。4.客户填写在线表格 要发出定单，客户必须填写在线表格关于运送和发票地址以及付款细节（信用卡或支票）。5.销售人员发送电子请求给仓库 在客户定单输入到系统

47、之后，销售人员发送电子请求给仓库，附上所订购的配置的细节。6.事务的细节email给客户 事务的细节，包括定单号和客户账号；要email给客户；使得客户可以在线查定单的状态。7.仓库获得发票并给客户运送计算机 仓库从销售售人员那里获得发票，并给客户运送计算机。参与者 图222显示了三个将表示在规格说明中的参与者，这些参与者是Customer，Salesperson和 Warehouse。2.2.2.2用例 用例表示一个完整的给用户传值的功能性单元。一个不与用例通信的参与者是没有意义的，但反之却不一定（即一个不与参与者通信的用例是允许的）。存在一些用例，它们泛化或特化了主要用例并且不直接与参与者

48、交互。它们在用例模型内部使用，并辅助主要用例为参与者提供结果。2.2.2.2用例 用例可以从对参与者的任务的标识中导出。这里要问的问题是参与者对系统的责任以及期望从系统中获得的是什么？用例还可以在对功能需求的分析中确定，在许多实例中，功能需求直接映射到用例。分析学习指导：第2步（在线购物）参照学习指导的第1步，并在这个在线购物应用中寻找用例。为了解决这个学习指导的问题，我们可以构造一个表，将功能需求赋予参与者和用例。注意，一些潜在的业务功能可能不在应用范围之内，它们不被转换为用例。表2l将学习指导第1步中列出的功能需求赋予参与者和用例，仓库配置计算机和将它运送给客户的任务就是超出范围的功能。用

49、例 图2-23展示了用例的UML图形表示，一个用例画成一个椭圆，并在椭圆的中间或下方带有一个名字。其他表示方法也是可能的（包括类长方形），以便用例的任何属性和操作可以被列出。2.2.2.3用例图 用例图将用例赋予参与者，如果存在用例之间的关系的话，它还允许用户建立这样的关系。这些关系将在第4章中论述。用例图是系统行为模型的主要可视化技术，需要进一步描述图元素（用例和参与者）以便提供完整的用例模型。分析学习指导：第3步（在线购物）参照学习指导的前面几步，为这个在线购物应用画用例图。这个步骤的一个解决方案可以用包含在前面几步中信息的直接获得。惟一需要另外考虑的可能是用例之间的关系。这个用例图如图2

50、24所示，关系的含义为：用例Order Configured Computer可以被Customer扩展为用例Request Salesperson Contact。2.2.2.4为用例编写文档 每个用例必须用事件流文档描述，这个正文式的文档定义了系统必须做什么和参与者什么时候激活用例。用例文档的结构可以改变，但通常情况下描述要包含：l涉及的参与者。l用例开始的前提条件。l事件流的详细描述，包括：事件的主流，可以划分来显示：l事件的子流（子流可以进一步划分为更小的子事件流，从而改进文档的可读性）。定义例外情景的替换流。l简述。l定义系统在用例结束后的后置条件。2.2.2.4为用例编写文档 用例