系统设计和实现-UML

第一章面向对象技术概述11.1软件危机及软件工程计算机软件发展的三个阶段程序设计阶段：50~60年代程序系统阶段：60~70年代软件工程阶段：70年代后231.1软件危机及软件工程为解决软件危机提出的软件开发模型瀑布模型快速原型方法螺旋式开发模型变换式开发模型增量式开发模型净室开发模型喷泉开发模型41.2对软件开发的基本认识大型软件的开发特点开发代价高开发时间长开发人员多软件生命周期长51.2对软件开发的基本认识传统软件工程开发大型软件的缺陷开发效率低产品质量差产品难以维护软件可移植性差软件可重用性差61.2对软件开发的基本认识软件开发过程需求分析总体设计详细设计代码实现测试运行和维护71.3软件的固有复杂性复杂性与计算机体系结构有关很难刻画软件系统的内在本质特征和规律软件系统中各元素之间的相互作用关系具有不确定性软件系统面临不断变化的压力软件系统必须根据硬件系统的变化不断调整软件设计人员缺乏理论的指导，开发具有很大的自由度81.4控制软件复杂性的基本方法分解对问题进行分解，然后再分别解决各个子问题抽象抽取系统中的基本特性，忽略非基本的特性。以便更充分地注意与当前目标有关的方面。人在同一时间里，一般只能集中于7项左右的信息，而不受信息的内容、大小等因素的影响。模块化高内聚、低耦合信息隐蔽（封装）把模块内的实现细节与外界隔离，用户只需要知道模块的功能，而不需要了解模块内部的细节。91.5面向对象技术面向对象（object-oriented,OO）面向对象=对象+类+继承+通信面向对象技术的优点开发出来的系统比较稳定开发的系统易于理解开发的系统具有更好的适应性，能更好地适应用户需求的变化，有助于构造大型软件系统。开发的系统具有更高的可靠性101.6面向对象领域中的基本概念对象（object）是系统中用来描述客观事物的一个实体，是构成系统的一个基本单位。一个对象由一组属性和对这组属性进行操作的一组方法组成。对象之间通过消息通信。实例（instance）一个可用于具体操作的对象。111.6面向对象领域中的基本概念类（class）是具有相同属性和方法的一组对象的集合。可以视为一个具有类似特性与共同行为的对象的模版。可以用来产生对象，类的实例是对象。类是静态的，类在程序执行前已定义好；对象是动态的，在程序执行时被创建和删除。121.6面向对象领域中的基本概念类Employee属性类名方法131.6面向对象领域中的基本概念Point类的设计与实现141.6面向对象领域中的基本概念封装（encapsulation）把对象的属性和方法结合成一个独立的系统单位，并尽可能地隐藏对象的内部细节。封装使对象形成两个部分接口部分：用户可见实现部分：用户不可见151.6面向对象领域中的基本概念继承（inheritance）使用已存在的类定义作为基础，建立新类的技术。继承增加了软件重用的机会，可降低软件开发和维护的费用。覆盖（override）子类中重新定义父类中的方法或属性。重载（overload）一个类中有多个同名的方法，但这些方法在操作数或/和操作数的类型上有区别。161.6面向对象领域中的基本概念单继承171.6面向对象领域中的基本概念多重继承181.6面向对象领域中的基本概念继承（inheritance）多重继承一个子类拥有多个父类。多重继承的问题：命名冲突C++：成员名限定解决Java：不支持多重继承，用接口来实现类似功能。191.6面向对象领域中的基本概念覆盖（override）201.6面向对象领域中的基本概念重载（overload）211.6面向对象领域中的基本概念多态（polymorphism）多态是允许你将父对象设置成为和一个或更多的它的子对象相等的技术。赋值之后，父对象就可以根据当前赋给它的子对象的特性以不同的方式运作。22第二章UML概述232.1为什么要学习UML什么是UMLUnifiedModelingLanguage（统一建模语言）是一种通用的模拟语言，可用于确定、展示和记录软件系统。UML中的图形标记非常适用于面向对象的软件设计。242.2UML的历史252.3UML的特点统一的标准面向对象可视化独立于过程概念明确262.4UML的构成UML构成图272.4UML的构成UML中几个图之间的关系282.5UML中的视图用例视图（usecaseview）表示系统的功能性需求逻辑视图（logicview）表示系统的概念设计和子系统结构实现视图（implementationview）用于说明代码的结构进程视图（processview）用于说明系统中并发执行和同步的情况部署视图（deploymentview）用于定义硬件结点的物理结构292.5UML中的视图302.6UML的应用领域软件系统建模描述非软件系统312.7支持UML的工具RationalRoseTogetherArgoUMLVisioVisualUML322.8一个UML的例子HelloWorld.java332.8一个UML的例子34第三章用例和用例图353.1用例用例是对一个活动者（actor）使用系统的一项功能时所进行的交互过程的一个文字描述序列。是系统、子系统或类和外部的参与者（actor）交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列。363.1用例用例的表示用一个椭圆表示用例的命名常用动宾结构或主谓结构命名用例373.1用例采用用例进行需求分析时的特点用例从使用系统的角度描述系统中的信息，不考虑系统内部对该功能的具体实现方式。用例描述了用户提出的一些可见需求，对应一个具体的用户目标。用例是对系统行为的动态描述，属于UML的动态建模部分。383.1用例采用用例进行需求分析时需注意不要试图把所有的需求都以用例的方式表示出来，用例只描述功能性需求。功能性需求：可用UML表示非功能性需求：难以用UML表示，可用附加补充文档来描述用例是一种功能分解技术，并未使用到面向对象的思想。用例是独立于具体实现的关于系统功能的描述。393.1用例协作（collaboration）在UML中可用于说明用例的实现。是对由共同工作的类、接口和别的元素所组成的群体的命名，这组群体提供合作的行为。用虚线椭圆表示。403.2参与者参与者（actor）指系统以外的、需要使用系统或与系统交互的东西，包括人、设备、外部系统等。一个参与者可以执行多个用例，一个用例也可以由多个参与者使用。参与者事实上就是类，因此参与者之间也存在继承（泛化，generalization）关系。413.2参与者参与者的表示形式423.2参与者例：银行业务系统的参与者客户：从系统获取信息并执行金融交易。管理人员：开办系统的用户。获取并更新信息。厂商：接受作为转帐支付结果的资金。Mail系统。433.3脚本脚本（scenario）指贯穿用例的一条单一路径，用于显示用例中的某个特殊情况。脚本是用例的实例。每个用例都包括一个主要脚本和多个次要脚本。脚本用具体的文字描述来表示。443.3脚本例：用例：订货脚本1：订货进行顺利的脚本脚本2：相关货源不足的脚本脚本3：涉及购货者的信用卡被拒的脚本453.4用例间的关系泛化关系（generalization）代表一般与特殊的关系，类似于继承。泛化关系中，子用例继承了父用例的行为和含义。子用例也可以增加新的行为和含义或覆盖父用例中的行为和含义。463.4用例间的关系用例之间的泛化关系473.4用例间的关系包含关系（include）指两个用例之间的关系，其中一个用例（基本用例，baseusecase）的行为包含了另一个用例（包含用例，inclusionusecase）的行为。在包含关系中，箭头的方向从基本用例指向包含用例，即基本用例依赖于包含用例。483.4用例间的关系用例之间的包含关系493.4用例间的关系扩展关系（extend）与泛化关系类似。基本用例必须声明若干“扩展点”，扩展用例只能在这些扩展点上增加新的行为和含义。503.4用例间的关系包含用例和扩展用例513.4用例间的关系用例的泛化、包含、扩展关系的比较泛化：isa扩展：isa包含：hasa523.4用例间的关系关系类型说明表示符号关联（association）actor和usecase之间的关系泛化（generalization）actor之间或usecase之间的关系包含（include）usecase之间的关系扩展（extend）usecase之间的关系533.4用例间的关系关系模型元素之间具体的语义联系。分为：关联、泛化、依赖、实现等。关联两个或多个类元之间的关系，描述了类元的实例之间的联系。泛化表示两个类元之间的关系。两个类元中，一个相对通用，另一个相对特殊。依赖两个元素或元素集之间的一种关系，被依赖的元素称作目标元素，依赖元素称作源元素。543.5用例图用例图（usecasediagram）是显示一组用例、参与者以及它们之间关系的图。553.5用例图金融贸易系统的用例图563.6用例的描述用例的描述应包含的内容用例的目标用例是怎么启动的参与者和用例之间的消息是如何传送的用例中除了主路径外，其他路径是什么用例结束后的系统状态其他需要描述的内容5758593.6用例的描述描述用例易犯的错误只描述系统的行为，没有描述参与者的行为只描述参与者的行为，没有描述系统的行为在用例描述中就设定对用户界面的设计的要求描述过于冗长603.6用例的描述存在问题的用例描述片断举例用例：取款参与者：储户主事件流储户插入ATM卡，并键入密码。储户按取款按钮，并键入取款金额。储户取走现金、ATM卡，并拿走收据。储户离开问题只描述了参与者的动作序列，没有描述系统的行为613.6用例的描述存在问题的用例描述片断举例用例：取款参与者：储户主事件流ATM系统获得ATM卡和密码。设置事务类型为取款。ATM系统获取要提取的现金数目。验证帐户上是否有足够的储蓄金额。输出现金、数据和ATM卡。系统复位。问题只描述了ATM系统的行为，没有描述参与者的行为。623.6用例的描述改进后的用例描述片断用例：取款参与者：储户主事件流通过读卡机，储户插入ATM卡。ATM系统从卡上读取银行ID、帐号、加密密码、并用主银行系统验证银行ID和帐号。储户键入密码，ATM系统根据上面读出的卡上加密密码，对密码进行验证。储户按取款按钮，并键入取款数量，取款数量应该是5美元的倍数。ATM系统通知主银行系统，传递储户帐号和取款数量，并接收返回的确认信息和储户帐户余额。ATM系统输出现金、ATM卡和显示帐户余额的收据。ATM系统记录事务到日志文件。633.7寻找用例的方法找出系统外部的参与者和外部系统，确定系统的边界和范围。确定每一个参与者所期望的系统行为。把这些系统行为命名为用例。使用泛化、包含、扩展等关系处理系统行为的公共或变更部分。编制每一个用例的脚本。绘制用例图。区分主事件流和异常情况的事件流，如果需要，可以把表示异常情况的事件流作为单独的用例处理。细化用例图，解决用例间的重复与冲突问题。643.7寻找用例的方法发现用例的启发性原则和用户交互把自己当作参与者，与设想中的系统进行交互。确定用例和确定参与者不能截然分开。653.7寻找用例的方法Jacobson的用例发现原则参与者的主要任务是什么？参与者需要了解系统的什么信息？需要修改系统的什么信息？参与者是否需要把系统外部的变化通知系统？参与者是否希望系统把异常情况的变化通知自己？663.8常见问题分析用例的粒度问题在一个系统中，有几个相似的功能，那么是将它们放在同一个用例中，还是分成几个用例？从用户需求的角度考虑，不要从数据处理的角度考虑。三层结构符合采用用例表示？一般在用例分析阶段不需考虑，如需描述可在类图、部署图中表示。673.8常见问题分析68第四章顺序图和协作图694.1交互图概述交互图（interactiondiagram）用于描述对象之间以及对象与参与者（actor）之间的动态协作关系以及协作过程中行为次序的图形文档。常用于描述一个用例的行为，显示该用例中所涉及的对象和这些对象之间的消息传递情况。704.1交互图概述形式顺序图（sequencediagram）着重描述对象按照时间顺序的消息交换。协作图（collaborationdiagram）着重描述系统成分如何协同工作。714.1交互图概述注意事项交互图可帮助分析人员对照检查用例描述的需求。可和类图相互补充类图对对象之间的消息交互情况表达不够详细。交互图不考虑类和对象，但可表示某几个对象之间的交互。交互图描述对象之间的消息发送关系。交互图一般不包括所有类的对象，但同一个类可以有多个对象出现在交互图中。724.2顺序图顺序图（时序图）是显示对象之间交互的图。对象是按时间顺序排列的。显示的是参与交互的对象及对象之间消息交互的顺序。734.2顺序图顺序图744.2顺序图顺序图的形式水平方向：对象垂直方向：时间包含的元素对象生命线（lifeline）控制焦点（focusofcontrol,FOC）消息（message）754.2顺序图顺序图的命名方式显示对象名和类名只显示类名只显示对象名764.2顺序图控制焦点的嵌套774.2顺序图激活期（activation）表示对象执行一个动作的期间，即对象激活的时间段。与控制焦点同义。784.3顺序图中的消息调用消息（procedurecall）可用来表示同步的意义。此消息的发送者把控制传递给消息的接收者，然后停止活动，等待消息接收者放弃或返回控制。消息的接收者一般是一个需要通过消息驱动才能执行动作的对象。调用消息必有一个配对的返回消息，为简洁起见，可不画出。794.3顺序图中的消息调用消息（procedurecall）调用消息（注意箭头）804.3顺序图中的消息异步消息（asynchronous）消息的发送者通过消息把信号传递给消息的接收者，然后继续自己的活动，不等待接收者返回消息或控制。发送者和接收者是并发工作的。814.3顺序图中的消息异步消息（asynchronous）UML规范说明1.4及以后版本中的异步消息UML规范说明1.3及以前版本中的异步消息824.3顺序图中的消息返回消息（return）表示从过程调用返回。如果从过程调用返回，则返回消息是隐含的，可不用画出。如果从非过程调用返回，则必须明确画出返回消息。834.3顺序图中的消息返回消息（return）844.3顺序图中的消息阻止消息（balking）是指消息发送者发出消息给接受者，如果接收者无法立即接收消息，则发送者放弃这个消息。854.3顺序图中的消息超时消息（timeout）是指消息发送者发出消息给接收者并按指定时间等待。如果接收者无法在指定时间内接收消息，则发送者放弃这个消息。864.3顺序图中的消息消息的语法格式[predecessor][guard-condition][sequence-expression][return-value:=]message-name([argument-list])874.3顺序图中的消息消息的语法格式predecessor：必须先发生的消息的列表。格式：sequence-number’,’…’/’guard-condition：警戒条件，表明只有在guard-condition满足时才发送该消息。格式：’[’boolean-expression’]’884.3顺序图中的消息消息的语法格式sequence-expression：消息顺序表达式。格式：sequence-term’.’…’:’sequence-term格式：[integer|name][recurrence]recurrence格式循环执行：’*’[’[’iteration-clause’]’] 例：*[i:=1..n]条件执行：’[’condition-clause’]’ 例：[x>y]894.3顺序图中的消息消息的语法格式return-value：将赋值为消息的返回值的名字列表。message-name：消息名。argument-list：消息的参数列表。904.3顺序图中的消息消息的例子2:display(x,y)简单消息1.3.1:p:=find(specs)嵌套消息，消息带返回值[x<0]4:invert(x,color)条件消息3.1*:update()循环消息A3,B4/C2:copy(a,b)线程间同步914.4建立顺序图的步骤确定交互过程的上下文（context）。识别参与交互过程的对象。为每个对象设置生命线，即确定哪些对象存在于整个交互过程中，哪些对象在交互过程中被创建和撤销。从引发这个交互过程的初始消息开始，在生命线之间自顶向下依次画出随后的各个消息。如果需要表示消息的嵌套，或/和表示消息发生时的时间点，则采用控制焦点。如果需要说明事件约束，则在消息旁边加上约束说明。如果需要，可以为每个消息附上前置条件和后置条件。924.5协作图协作图用于描述系统的行为是如何由系统的成分协作实现的图。协作图中的建模元素对象参与者实例多对象（multipleinstance）：由多个对象（通常属于同一个类）组成的对象集合。主动对象：对象中至少有一个方法不需要接收消息就能主动执行。消息：与顺序图相同。链（link）：用于连接对象，消息显示在链旁边，一个链上可以有多个消息。934.5协作图1、GUI将击键事件通知操作系统2、操作系统通知CPU3、操作系统更新GUI数据4、CPU通知图形卡5、图形卡向显示器发送一个消息6、显示器将图形显示在屏幕上944.6建立协作图的步骤确定交互过程的上下文。识别参与交互过程的对象。如果需要，为每个对象设置初始特性。确定对象之间的链（link），以及沿着链的消息。从引发这个交互过程的初始消息开始，将随后的每个消息附到相应的链上。如果需要表示消息的嵌套，则用Dewey十进制数表示法。如果需要说明时间约束，则在消息旁边加上约束说明。如果需要，可以为每个消息附上前置条件和后置条件。954.7顺序图和协作图的比较都属于交互图。都用于描述系统中对象之间的动态关系。两者各相互转换，但侧重点不同。顺序图强调消息的时间顺序。协作图强调参与交互的对象的组织。建模元素顺序图有对象生命线和控制焦点。协作图有路径，消息必须有消息顺序号。964.7顺序图和协作图的比较顺序图易于表达算法、对象的生命期、具有多线程特征的对象。协作图易于表达并发控制流。974.8工具支持支持模型以动画的方式执行的工具支持软件开发的正向工程和逆向工程的工具984.9常见问题分析消息循环发送的表示方法消息名前加循环条件例：1.1*[forallorderlines]:message1()2.1*[i:=1..n]:message2()994.9常见问题分析消息条件发送的表示方法在消息上加警戒条件[x<0]4:invert(x,color)在消息名字前加条件子句[x>y]是用文字说明分成多个顺序图1004.9常见问题分析1014.9常见问题分析时间约束的表示方法1024.9常见问题分析递归的表示方法1034.9常见问题分析递归的表示方法104第五章类图和对象图1055.1类的定义类名simplename简单的名词形式的名称pathname包名:类名类的属性[可见性]属性名[:类型][’[’多重性[次序]’]’][=初始值][{特性}]1065.1类的定义类属性举例+size:Area=(100,100)#visibility:Boolean=false+default-size:Rectangle-xptr:XwindowPtrcolors:Color[3]points:Point[2..*ordered]name:String[0..1]1075.1类的定义类的操作（operation）[可见性]操作名[(参数列表)][:返回类型][{特性}]类操作举例+display():Location+hide()#create()-attachXWindow(xwin:XwindowPtr)1085.2类之间的关系关联（association）是模型元素间的一种语义联系，是对具有共同的结构特性、行为特性、关系和语义的链的描述。链：关联的实例。表示对象与对象之间的关系。类之间的关联关系类之间的单向关联关系1095.2类之间的关系publicclassA{publicBtheB;

/***roseuid4173D9B30278*/publicA(){

}}publicclassB{

/***roseuid4173D9A90007*/publicB(){

}}1105.2类之间的关系关联名描述关联的作用通常是动词或动词短语1115.2类之间的关系关联的角色1125.2类之间的关系关联类1135.2类之间的关系publicclassCompany{privateStringcompanyName;publicPersonemployee[];

/***roseuid4173E1BD014B*/publicCompany(){

}}publicclassPerson{privateStringpersonName;publicCompanyemployer;

/***roseuid4173E1BD03CC*/publicPerson(){

}1145.2类之间的关系publicclassContract{privateDoublesalary;

/***roseuid4173E1BE01C4*/publicContract(){

}}1155.2类之间的关系关联的约束带约束的关联1165.2类之间的关系限定关联带有限定符的关联。限定符在给定关联一端的一个对象和限定符值以后，可确定另一端的一个对象或对象集。是关联的属性。可根据多重性判断限定符的设计是否合理。引入限定符的目的是把多重性从n降为1或0..1，若点定符另一端的多重性仍为n，则需考虑设计的合理性。1175.2类之间的关系限定关联限定符和限定关联限定关联和一般关联1185.2类之间的关系限定关联1195.2类之间的关系关联的种类自返关联（reflexive/recursiveassociation）一个类与自身的关联。是一个类的两个对象间的关系。关联两端的角色不同。1205.2类之间的关系publicclassEnginPart{publicEnginParttheEnginPart[];

/***roseuid4173FA3F0070*/publicEnginPart(){

}}1215.2类之间的关系关联的种类二元关联（binaryassociation）两个类之间的关联1225.2类之间的关系关联的种类N元关联（n-aryassociation）3个或3个以上的类之间的关联。1235.2类之间的关系聚集和组合聚集（aggregation）表示类之间整体与部分的关系。聚集关系的判定“包含”，“组成”，“分为……部分”聚集关系Circle不存在，不一定意味着Style不存在。1245.2类之间的关系聚集和组合组合（composition）表示类之间整体与部分的关系。整体与部分具有同样的生存期。是特殊的聚集组合关系Circle不存在，则圆心Point也不存在。1255.2类之间的关系聚集和组合的区别聚集关系组合关系has-acontains-a表示事物的整体/部分关系较弱的情况。表示事物的整体/部分关系较强的情况。代表部分事物的对象可以属于多个聚集对象，可以为多个聚集对象所共享，且可随时改变所从属的聚集对象。一旦删除了一个聚集对象，不一定随即删除代表部分事物的对象。代表整体事物的对象负责创建和删除代表部分事物的对象，代表部分事物的对象只属于一个组合对象。一旦删除了组合对象，随即删除了相应的代表部分事物的对象。1265.2类之间的关系泛化关系类与类之间的泛化关系=类与类之间的继承关系。1275.2类之间的关系依赖关系（dependency）假设有两个元素X、Y，若对X的定义的修改会导致对Y的定义的修改，则Y依赖于X。依赖关系不生成专门的实现代码。若两个类存在关联关系，则一般只表示关联关系即可，不必再表示依赖关系。add和remove的参数均为Course类型，因此Schedule依赖于Course。1285.3派生属性和派生关联派生属性（derivedattribute）和派生关联（derivedassociation）指可以从其它属性和关联推演得到的属性和关联。派生属性和派生关联不产生相应代码。1295.3派生属性和派生关联派生属性1305.3派生属性和派生关联派生关联1315.4抽象类和接口抽象类（abstractclass）不能直接产生实例的类。抽象类中的方法往往只是一些声明，没有具体实现。类名用斜体字表示。当需要提供一系列子类的模板时，采用抽象类。1325.4抽象类和接口抽象类1335.4抽象类和接口接口（interface）当没有所需要功能的父类，以及需要调用与类无关的功能时，定义接口。接口还可以作为“标记”，指示一个类的某些特性。1345.4抽象类和接口抽象类接口可包含属性不能包含属性可提供某些方法的具体实现所有声明的方法均不实现1355.5版型（stereotype）版型是建模人员在已有的构造块上派生出的新构造块，这些新构造块是和特定问题相关的。UML的主要类版型边界类（boundaryclass）控制类（controlclass）实体类（entityclass）UML中的一些预定义版型接口-类子系统-包1365.6边界类、控制类和实体类边界类位于系统与外界的交接处。如：窗体，对话框，报表，通信协议类，直接与外部设备或系统交互的类。Icon形式Label形式Decoration形式1375.6边界类、控制类和实体类多个参与者使用同一个边界类1385.6边界类、控制类和实体类实体类保存要放进持久存储体（数据库、文件等）的信息。通常实体类对应数据库中相应的表，实体类的属性对应数据表中的字段。Icon形式Label形式Decoration形式1395.6边界类、控制类和实体类控制类负责其它类工作的类。Icon形式Label形式Decoration形式1405.7类图类图描述类和类之间的静态关系。类图显示了信息的结构，并描述了系统的行为。1415.7类图类图的抽象层次概念层（conceptual）描述应用领域中的概念，应独立于程序设计语言。说明层（specification）描述软件的接口部分。实现层（implementation）考虑类的实现问题，提供类的实现细节。1425.7类图概念层说明层实现层1435.7类图构造类图的步骤研究分析问题领域，确定系统的需求。确定类，明确类的含义和职责，确定属性和操作。确定类之间的关系。把类之间的关系用关联、泛化、聚集、组合、依赖等关系表达出来。调整和细化已得到的类和类之间的关系。绘制类图并增加相应说明。1445.8领域分析通过对某一领域中的已有应用系统、理论、技术、开发历史等的研究，来标识、收集、组织、分析和表示领域模型及软件体系结构的过程。根据上面的过程得到的结果。1455.9OO设计的原则开闭原则Liskov原则依赖倒置原则接口分离原则1465.9OO设计的原则开闭原则指一个模块在扩展性方面应该是开放的，而在更改性方面应该是封闭的。编写模块时，应尽可能使得模块可扩展，且在扩展时不需要对模块的源代码进行修改。为保证开闭原则，需：有意识地使用接口进行封装。采用抽象机制。利用多态技术。1475.9OO设计的原则开闭原则打印输出设计1打印输出设计21485.9OO设计的原则Liskov替换原则子类可以替换父类出现在父类能出现的任何地方。1495.9OO设计的原则依赖倒置原则指依赖关系应该是尽量依赖接口（或抽象类），而不是依赖于具体类。比较结构化设计中的依赖关系高层模块依赖于低层模块，越低层越与实现细节有关。高层模块往往通过调用低层模块实现，抽象的模块要依赖于与具体实现有关的模块。面向对象设计中的依赖关系低层模块依赖于高层模块。与具体实现有关的类依赖于抽象类或接口。1505.9OO设计的原则依赖倒置原则1515.9OO设计的原则依赖倒置原则面向对象设计中的依赖关系1525.9OO设计的原则接口分离原则指在设计时采用多个与特定客户类有关的接口比采用一个通用的接口要好。一个类要给多个客户类使用，则可以为每个客户类创建一个接口，然后为这个类实现所有这些接口。不要只创建一个接口，其中包含了所有客户类需要的方法，然后用这个类实现这个接口。1535.9OO设计的原则接口分离原则使用通用接口的设计Service中方法的改变将导致ClientA、ClientB、ClientC和ServiceImp的重新编译。1545.9OO设计的原则接口分离原则使用分离接口的设计1555.9OO设计的原则需注意的设计问题不同类中相似方法的名字应该相同。遵守已有的约定俗成的习惯。尽量减少消息模式的数目。设计简单的类，类的职责要明确。泛化结构的深度要适当。定义简单的方法。1565.9OO设计的原则好的设计变动轨迹1575.10对象图对象图表示一组对象及它们之间的联系。是系统的详细状态在某一时刻的快照（snapshot），常用于表示复杂的类图的一个实例。UML中对象图与类图具有相同的表示形式。158第六章数据建模1596.1数据建模概述E-R（entity-relationship）图着眼于数据，不能对行为建模。UML用类图扩充E-R图。用类图描述数据库模式。用类描述数据库表。用类的操作来描述触发器和存储过程。1606.2数据库设计的基本过程1616.2数据库设计的基本过程概念设计把用户的信息要求统一到一个整体逻辑结构中，此结构能表达用户的要求，且独立于任何数据库管理系统软件和硬件。逻辑设计把概念设计阶段得到的结果转换为与选用DBMS所支持的数据模型相符合的逻辑结构。物理设计对给定的逻辑数据模型选取一个最适合应用要求的物理结构。162数据库中的概念版型所应用的UML元素数据库<<Database>>构件（Component）模式<<Schema>>包（Package）表<<Table>>类（Class）视图<<View>>类域<<Domain>>类索引<<Index>>操作（Operation）主键<<PK>>操作外键<<FK>>操作惟一性约束<<Unique>>操作检查约束<<Check>>操作触发器约束<<Trigger>>操作存储过程<<SP>>操作表与表之间非确定性关系<<Non-Identifying>>关联、聚集表与表之间确定性关系<<Identifying>>组合数据建模时用到的一些版型1636.3数据库设计的步骤创建数据库对象创建模式创建包和域创建数据模型图创建表创建列创建关系必要时对数据模型进行规范化表要时对数据模型进行优化实现数据模型1646.3数据库设计的步骤在构件视图（componentview）中创建数据库对象默认的目标数据库为ANSISQL92，用户可以更改为其他类型的数据库。1651661671686.3数据库设计的步骤在逻辑视图（logicalview）中创建模式，并选定目标数据库1691701716.3数据库设计的步骤在逻辑试图中创建域包和域创建域包创建域域：定制的数据类型，可为每个域加上检查语句。172创建域包173创建域包174创建域175创建域1766.3数据库设计的步骤创建数据模型图创建表创建列177创建数据模型图178创建表和列1796.3数据库设计的步骤创建表与表之间的关系非确定性（non-identifying）关系子表不依赖于父表，可脱离父表单独存在。版型：<<Non-Identifying>>强制（mandatory）的非确定性关系父表一端的多重性为1或1..n。可选的（optional）的非确定性关系父表一端的多重性为0..1或0..n（允许外键为空）。确定性（identifying）关系子表不能离开父表单独存在。版型：<<Identifying>>1806.3数据库设计的步骤强制（mandatory）的非确定性关系1816.3数据库设计的步骤可选（optional）的非确定性关系1826.3数据库设计的步骤确定性关系1836.4对象模型和数据模型的转换对象模型转换为数据模型类→表类与类之间的关系→表与表之间的关系类与类之间的关系→表1846.4对象模型和数据模型的转换对象模型转换为数据模型的步骤在构件视图下创建数据库对象在逻辑视图下创建包，并在包中创建类（类必须设置Persistent属性）。在包的快捷菜单中选择“TransformtoDataModel”创建数据模型图，把自动生成的表拖到数据模型图中。1856.4对象模型和数据模型的转换对象模型转换为数据模型的步骤在逻辑图下创建包，并在包中创建类1866.4对象模型和数据模型的转换对象模型转换为数据模型的步骤1876.4对象模型和数据模型的转换对象模型转换为数据模型的步骤1886.4对象模型和数据模型的转换对象模型转换为数据模型的步骤1896.4对象模型和数据模型的转换数据模型转换为对象模型表→类表与表之间的关系→类与类之间的关系1906.4对象模型和数据模型的转换数据模型转换为对象模型的步骤把一个模式中的所有表及其关系转换为对象模型，不对单个的表进行转换。将转换得到的类放到类图中显示。191第七章包1927.1包的基本概念包是一个包含建模元素的容器。1937.1包的基本概念包的命名简单包名例：Vision带路径的包名例：Sensors::Vision1947.2设计包的原则重用等价原则把类放入包时，应考虑把包作为可重用的单元，要方便对包的各个版本的管理。共同闭包原则把需要同时改变的类放在一个包中。共同重用原则不会一起使用的类不放在同一包中。非循环依赖原则包之间的依赖关系不要形成循环。195第八章状态图和活动图1968.1什么是状态图状态图（statechartdiagram）用于描述一个对象在其生存其间的动态行为，表现一个对象所经历的状态序列，引起状态转移的时间，和因状态转移而伴随的动作。1978.1什么是状态图状态图应在具有以下特性的属性上建模属性拥有较少的可能取值属性在这些值之间的转移有一定的限制1988.1什么是状态图状态机是一个状态和转换的图，描述了类元实例对事件接收的响应。状态机可以附属于某个类元（类或用例），还可以附属于协作和方法，状态机附于的元素被称为状态机的主机。状态图用于显示状态机，重点描述状态之间的控制流。1998.1什么是状态图状态机Mootr机所有动作都与状态相关的状态机。Mealy机所有动作都与转移有关的状态机。2008.2状态图中的基本概念状态（state）指在对象的生命期中的某个条件或状况，在此期间对象将满足某些条件、执行某些活动或等待某些事件。所有对象都具有状态。状态是对象执行了一系列活动的结果。某事件发生后，对象的状态将发生变化。2018.2状态图中的基本概念状态的组成部分状态名（name）进入/退出动作（entry/exitaction）内部转移（internaltransition）子状态（substate）延迟事件（deferredevent）2028.2状态图中的基本概念状态的类型初态只能有一个。终态可有一个或多个，也可没有。中间状态名字域内部转移域组合状态历史状态2038.2状态图中的基本概念状态的例子2048.2状态图中的基本概念组合状态和子状态子状态（substate）嵌套在另一个状态中的状态。组合状态（compositestate）一个含有子状态的状态。2058.2状态图中的基本概念组合状态和子状态组合状态和子状态2068.2状态图中的基本概念子状态之间的or关系某一时刻仅可达到一个子状态。2078.2状态图中的基本概念子状态之间的and关系组合状态中，某一时刻仅可达到多个子状态。2088.2状态图中的基本概念历史状态（historystate）目的是记住从组合状态中退出时所处的子状态。当再次进入组合状态时，可直接进入这个状态，而不必从组合状态的初始开始。是一个伪状态（pseudostate）。潜历史状态只记住最外层组合状态的历史。深历史状态可记住任何深度的组合状态的历史。2098.2状态图中的基本概念数据备份的状态图2108.2状态图中的基本概念转移（transition）是两个状态之间的一种关系，表示对象将在第一个状态中执行一定的动作，并在某个特定事件发生而且某个特定的警戒条件满足时进入第二个状态。状态之间的转移可由事件触发，亦可由源状态的内部活动执行完毕后自动触发转移。一个给定的状态，最终只能产生一个转移。2118.2状态图中的基本概念转移的描述格式 event-signature’[’guard-condition’]’’/’actionevent-signature：事件特征标记。格式： event-name‘(‘comma-separated-parameter-list‘)’guard-condition：警戒条件。action：动作。例： targetAt(p)[isThreat]/t.addTarget(p)2128.2状态图中的基本概念相互之间互斥的转移2138.2状态图中的基本概念相互之间互斥的转移2148.2状态图中的基本概念事件（event）是对一个在时间和空间上占有一定位置的有意义的事情的详细说明。事件产生的原因调用满足条件的状态出现到达时间点经历某一时间段发送信号2158.2状态图中的基本概念事件的分类调用事件（callevent）表示对操作的调度。 event-name‘(‘comma-separated-parameter-list‘)’调用事件2168.2状态图中的基本概念事件的分类变化事件（changeevent）如果一个布尔表达式中的变量发生变化，使得该布尔表达式的值相应地变化，从而满足某些条件，则这种事件称作变化事件。变化事件的关键词：when。变化事件2178.2状态图中的基本概念事件的分类变化事件（changeevent）变化事件和警戒条件的区别警戒条件是转移说明的一部分。警戒条件在相关事件出现后只计算一次。变化事件表示的是一个不断被测试的事件。2188.2状态图中的基本概念事件的分类时间事件（timeevent）指满足某一事件表达式的情况的出现。如：到达某一时间，经过某一时间段。时间事件的关键字：after，when。时间事件2198.2状态图中的基本概念事件的分类信号事件（signalevent）表示对象接收到了信号这种情况。常会触发状态的转移。信号：由一个对象异步地发送，并由另一个对象接收的已命名的对象。信号之间可具有泛化关系，用版型为<<signal>>的类表示。220信号之间的泛化关系2218.2状态图中的基本概念动作（action）是一个可执行的原子计算。即，动作不可被中断，其执行时间可忽略不计。动作的描述可用某种合适的程序设计语言的语法来描述。特殊的动作进入动作（entryaction）‘entry’‘/’action-expression退出动作（exitaction）‘exit’‘/’action-expression2228.3状态图的工具支持正向工程根据状态图生成代码。RationalRose不支持，Poseidon支持。逆向工程根据源代码得到状态图。2238.4什么是活动图用于描述系统的工作流程和并发行为。可视作状态图的特殊形式。活动图中一个活动结束后立即进入下一个活动。2248.5活动图中的基本概念活动（activity）表示某流程中的任务的执行，可以表示某算法过程中语句的执行。动作状态（actionstate）是原子的，不能被分解，没有内部转移，没有内部活动。动作状态的工作所占用的时间是可忽略的。目的是执行进入动作，然后转向另一个状态。可被视作活动状态的特例。活动状态（activitystate）不是原子的，可分解。活动状态的工作的完成需要一定的时间。2258.5活动图中的基本概念泳道（swimlane）是活动图中的区域划分。根据每个活动的职责对所有活动进行划分，每个泳道代表一个责任区。一个泳道可能由一个或多个类来实现。2262278.5活动图中的基本概念分支（branch）对于同一个触发事件，可以根据不同的警戒条件转向不同的活动，每个可能的转移是一个分支。分支的两种表示方法2288.5活动图中的基本概念分叉（fork）和汇合（join）用于表示系统或对象的并发行为。分叉表示一个控制流被两个或多个控制流代替。经过分叉后，这些控制流是并发进行的。汇合表示两个或多个控制流被一个控制流代替。2298.5活动图中的基本概念2308.5活动图中的基本概念对象流在活动图中使用对象作为活动的输入或输出。对象流表示活动和对象之间的关系。2312328.6活动图的用途表示并发行为对系统的工作流程（业务过程）建模对系统的具体操作建模描述计算过程的细节（算法）2338.6活动图的用途例1：产品制造和发货的用例234235第九章构件图2369.1什么是构件和构建图构件（component）是系统中遵从一组接口且提供其实现的物理的、可替换的部分。构件图（componentdiagram）显示一组构件以及它们之间的相互关系、包括编译、链接或执行时构件之间的依赖关系的视图。2379.1什么是构件和构建图2389.1什么是构件和构建图构件的类型部署构件（deploymentcomponent）如：dll文件，exe文件，COM+对象，CORBA对象，EJB、动态Web页，数据库表。工作产品构件（workproductcomponent）如：源代码文件，数据文件。执行构件（executioncomponent）系统执行后得到的构件。2399.1什么是构件和构建图构件和类的区别类是逻辑抽象，构件是物理抽象。构件是对其他逻辑元素的物理实现。类可以有属性和操作，构件通常只有操作，且这些操作只能通过构件的接口才能使用。2409.2构件图的作用对源代码文件之间的相互关系建模对可执行文件之间的相互关系建模2419.3构件图的工具支持正向工程逆向工程242第十章部署图24310.1什么是部署图部署图（deploymentdiagram）用来显示系统中计算结点的拓扑结构和通信路径与结点上运行的软构件等。一个系统模型只有一个部署图，常被用于帮组理解分布式系统。244部署图24510.2部署图中的基本概念结点（node）存在于运行时的代表计算资源的物理元素，节点一般都具有一些内存，且常具有处理能力。可代表一个物理设备以及运行该设备上的软件系统。分类处理机（processor）可以执行程序的硬件构件。设备（device）无计算能力的硬件构件。24610.2部署图中的基本概念连接（connection）表示两个硬件之间的关联关系。是结点之间的连线，表示系统之间进行交互的通信路径。24710.3部署图的例子例1：PC、外设、ISP的互连248第十二章业务建模24912.1业务建模概述业务建模的目的捕获较准确的用户需求，为后续软件系统的分析与设计提供依据。业务建模针对的几个方面对象过程事件地点社会-政治25012.1业务建模概述业务模型和软件系统的关系25112.2业务建模中的基本概念目标（goal）业务试图要达到的结果，即希望资源处于什么样的状态。过程（process）在业务中被执行的活动，这些活动会改变资源的状态。资源（resource）是在业务中使用或产生的对象。规则（rule）对业务中的某些方面进行规定或约束的声明，是业务知识的一种表示形式。包括功能性、行为性、结构性三类。25212.3UML的业务建模扩展使用UML进行业务建模的好处概念上相似技术成熟标准化的符号有助于消除业务模型和软件模型之间的鸿沟25312.3UML的业务建模扩展Rose对业务建模的扩展业务参与者是机构外部与机构交互的一切人或事物每个参与者都与机构中的业务活动有关是类的<<BussinessActor>>版型25412.3UML的业务建模扩展Rose对业务建模的扩展业务工人是机构内部扮演一定角色的人是类的<<BussinessWorker>>版型25512.3UML的业务建模扩展Rose对业务建模的扩展业务实体业务过程中要使用或产生的对象是类的<<BussinessEntity>>版型25612.3UML的业务建模扩展Rose对业务建模的扩展业务用例是机构中为外部业务参与者提供价值的一组相关工作流用于表示一个机构要做什么是用例的<<BussinessUseCase>>版型25712.3UML的业务建模扩展Rose对业务建模的扩展机构单元是业务工人、业务实体和其他业务模型元素的集合是包的<<organizationUnit>>版型25812.4业务体系结构进行业务建模需要考虑的问题机构的边界以及这个机构要与谁通信机构中的工作流以及如何对工作流进行优化模型的详细程度过于粗略对理解机构中的业务过程帮组不大过于详细使得业务过程中的关键部分不突出25912.5从业务模型到软件模型对软件系统建模时，业务模型的作用：帮助确定什么样的软件系统对于机构中的业务过程是最合适的。帮助定义功能性需求。帮助定义非功能性需求。作为分析和设计软件系统的基础。帮助识别封装了业务功能的业务构件。260第十三章Web建模26113.1Web建模的基本概念Web建模时需要考虑的问题如何表示Web应用系统的体系结构如何表示Web应用系统中一些特有的概念和传统分布式应用系统的区别连接的持久性Web应用中客户机和服务器之间的连接时暂时的客