《接口组件节点课件.ppt》由会员分享，可在线阅读，更多相关《接口组件节点课件.ppt（83页珍藏版）》请在三一办公上搜索。
1、2023/3/21,1,第5讲 包图组件图物理图,2023/3/21,2,内容,包图从逻辑到物理实现我们已经完成了逻辑模型的学习本讲中我们要学习物理模型的表示物理图的构成:组件图和配置图,2023/3/21,3,1.包图,2023/3/21,4,1.1 包的引入,大型的软件系统中往往包含大量的建模元素需要将它们有序的组织起来包就是一种概念性的模型管理的图形工具,2023/3/21,5,1.2包的语义,包是一种对模型元素进行成组组织的通用机制。包用于定义一个名字空间或容器（Container)。运用包可以把语义上相近的可能一起变更的模型元素组织在同一个包中，对包中的元素作为一个整体对待，并且控制
2、它们的可视性和存取。包纯粹是一种概念性的模型元素，只存在于软件的开发过程中，因而与组件的概念是不一样的。,2023/3/21,6,1.3 包的表示,GUI,GUI,COMMON:GUIVersion 1.2,+窗口+表格事件处理,简单名字,路径名字Common是GUI所属的包,包的性质,拥有的对象类,2023/3/21,7,包拥有内容，包括类、接口、组件、节点、协同。Use Case、图，甚至其它包包与它所含的模型元素之间的关系是一种组合联系，即一个包由一个或多个模型元素组成，每一个模型元素都在该包中申明，一个模型元素只能为一个包唯一地拥有，一个包消失了，该包中所有元素都消失不同包中的元素可以
3、同名，但是同一包中的模型元素不能同名,2023/3/21,8,包的模型元素名前可以有可视性标志，其表示方法与类中的属性和操作的可视性表示一样。，对于输入该包的任何包的模型元素都可见，对于外包不可见，只对其子包可见,+订货表+追踪表订货,客户机,2023/3/21,9,1.4包的嵌套,包可以拥有其它包作为包内的元素，子包又可以拥有子包，这样就构成一个嵌套结构包的嵌套层次不能太多，一般最多不超过23层,2023/3/21,10,import,import,import,access,access,控制器,图形元素,领域元素,图形内核,编辑器,通用的图形编辑器,2023/3/21,11,图形元素,图
4、形内核,领域元素,控制器,另一种表达,只能表示构成，不能表示依赖,2023/3/21,12,1.5 标准构造型,构造型和标记值说明其特定的性质，如包的作者，提供的服务等facade:一个包仅仅是其它一些包的视图framework:代表模型架构stub:一个包是另一个包的公共内容的服务代理subsystem：子系统system：代表一个系统模型,2023/3/21,13,1.6 包的联系,主要有两种：依赖泛化,2023/3/21,14,1.6.1 依赖,依赖：一个元素的定义的改变会引起另一个元素发生相应改变如对于类而言，一个类作为另一个类的数据的一部分，一个类用另一个类作为操作的参数等两个包之间
5、存在依赖是指两个包所含的模型元素之间存在着一个或多个依赖。依赖关系的表示：用虚箭线从依赖包指向独立包,2023/3/21,15,领域,2023/3/21,16,包的依赖关系没有传递性包的依赖关系可以加上许多构造型规定它的语义，其中最常见的是输入依赖输入依赖(Import Dependency)是包与包之间的一种存取(Access)依赖关系。输入(importing)允许一个包中的元素存取另一个包中的元素输入依赖是单向的。,2023/3/21,17,包的公共部分，即可视性为公共的模型元素，称为包的输出，包的输出只对另一个与它有输入依赖的包才是可视的，可存取的输入依赖的表示，是在虚箭线上标有构造型
6、import，箭头的方向从输入方的包指向输出方的包表达存取依赖的另一构造型是Access,import把目标包的内容加到源包的名字空间，因而无需限定（指出）它们的名称Access不把目标包的内容加到源包的名字空间，因而需要指出它们的名称,2023/3/21,18,客户机,订货表追踪表订货,订货规则GUI:窗口,窗口表格事件处理,策略,GUI,import,import,对于“策略”包中的类可视,对于“策略”包中的类不可视,2023/3/21,19,1.6.2 泛化,与类的泛化关系一样：表示一般与特殊的关系两个包之间存在泛化关系，指其中的特殊性包必须遵循一般性包的接口。与类的继承相同，特殊包一般
7、继承其所包含的公共类，并且可以重载和添加自己的类。,2023/3/21,20,1.7 包图,包与包之间的联系（依赖与泛化）构成包图包与对象类在形式上类似，但是，包是组织模型的一种机制，不存在实例，而对象类是对问题领域的事物的一种抽象，存在实例。,2023/3/21,21,1.7.1 包图的建立,小型系统可以不使用包对于大型的复杂系统，通常需要建立包图，以便于理解和处理整个模型建立包图的步骤如下：分析系统模型元素，把概念上和语义上相近的模型元素纳入一个包如何确定“相近”性？如果一个类的行为和/或结构的变更要求另一个类作出相应的变更如果删除一个类后，另一个类便成为多余的如果两个类之间有大量的频繁交
8、互或通信如果两个类之间有一般/特殊关系如果一个类激发创建另一个类的对象,2023/3/21,22,对于每一个包，标出其模型元素的可视性确定包与包之间的依赖关系确定包与包之间的泛化联系绘制包图精化,2023/3/21,23,1.7.2 系统建模,利用包图可以对系统的建模系统的结构可以以不同的角度和观点建立,2023/3/21,24,2023/3/21,25,imports,imports,2023/3/21,26,一个大型复杂的系统可以分成若干个功能相对独立的子系统。系统和子系统都可以用一个包表示，但分别加上构造型System和subsystem来表示系统:目的事物,它由一组系统元素组成,能完成
9、整个任务子系统:系统元素组成,系统的相对独立的部分模型:现实世界的简化,是系统的抽象视图:模型的投影,从不同角度反映系统模型,2023/3/21,27,2023/3/21,28,1.7.3开发跟踪,是一种依赖联系,说明它所连接的两个模型元素是同一个概念的模型元素,只是位于不同的抽象层上需求到实现版本之间,销售管理version=5.1,销售管理version=5.2,销售管理可视说明,2023/3/21,29,2.组件图,2023/3/21,30,2.1 组件的定义与表示,组件(component)是系统的物理的可替换的单元,它把系统的实现打包,并且提供一组接口的实现(realization)
10、组件代表系统的一个物理实现块，代表逻辑模型元素如类、接口、协同的物理实现。组件本身遵从和提供一组接口的实现，它们代表了由驻留在组件内部的模型元素所实现的服务常见的组件有系统的配置组件,如COM+组件,Java Beans等.组件也可以是软件开发中的产物,如源代码,二进制码,可执行代码等,2023/3/21,31,组件的图标,Image.java,System:dialog.dllversion=2.0,简单名字,路径名字,描述特性,2023/3/21,32,Mailer,+Mailbox,+RoutingList,-MailQueue,myMailer:Mailer,:Mailbox,:Rou
11、tingList,:MailQueue,扩充组件,组件中的类,组件实例，存在于运行期间，用于配置图,匿名对象,可视性,2023/3/21,33,组件与类相比相同点:都有名字,都有实例,都能实现接口,都有联系区别:组件代表物理事物,类代表事物的逻辑抽象,因此组件可以出现在配置图中,类则不可以.一般组件只有操作,外界通过接口接触它们,而类可以直接有属性和操作联系:一个类可以由一个或多个组件实现.组件和类的关系为依赖关系.组件与包相比组件代表一个物理的代码模块,包可以包含成组的逻辑模型元素,也可以包含物理的组件,一个对象类可以出现在多个组件中,却只能出现在一个包中,2023/3/21,34,组件提供
12、接口的实现,一个组件可以实现一个或多个接口,字典,拼写检查,同义词,2023/3/21,35,2.2 组件的种类,配置组件(Deployment Component)构成可执行系统必须的组件,如动态链接库(DLL),执行程序(EXE)等.工作产品组件(Work Product Component)软件开发阶段用的组件,包括源程序文件,数据文件等.它们并不直接构成执行系统,配置组件根据工作产品组件建立执行组件(Execution Component)是执行系统的部件,如COM+对象,它是执行动态链接库的实例,2023/3/21,36,2023/3/21,37,UML的所有扩展机制都可以用于组件,
13、如加标记值以描述性质,使用构造型规定其种类标准构造型:可在节点上执行的组件:静态的或动态的对象库:数据库表:文档,代表源代码或数据:文档,2023/3/21,38,2.3组件的联系,组件之间可以有依赖联系:一个组件的模型元素使用另一个组件的模型元素组件也可以通过接口实现依赖联系简单表示法扩充接口表示法,2023/3/21,39,Image.java,Component.java,ImageObserver,Image.java,Component.java,ImageObserverAbort:intfinal staticError:intfinal staticimageUpdate():
14、boolean,扩展成一个接口类,实现该接口,2023/3/21,40,由一个组件实现的接口称为输出接口(Export Interface),表示该接口是组件提供给其他组件的服务.一个组件可以提供多个输出接口.为一个组件使用的接口称为输入接口(Import Interface)通过输入接口和输出接口所实现的组件之间的依赖成为输入依赖(Import Dependency),2023/3/21,41,依据不同开发阶段,可以将依赖分为:开发期间的依赖调用依赖开发期间的依赖(Development-time Dependency)是指在编译阶段和连接阶段的组件之间的通信或调用联系.,供应者,客户,20
15、23/3/21,42,调用依赖(Call Dependency):指一个组件调用或使用另一个组件的服务,供应者对象,客户,供应者,客户,供应者对象,客户,服务,服务,2023/3/21,43,2.4 组件图的应用,组成:组件,接口,组件之间的联系表示系统中的不同物理部件及其联系组件图是“型”的概念,表示组件的实例需要使用配置图组件图的作用:组件图表示系统的静态依赖,例如程序间的编译依赖组件图可以为下列事物建立模型:系统的源代码,系统的发布版本,物理数据库,自适应系统组件图也可以建立业务模型,表示业务的过程和文档组件图也可以表示软件产物的依赖关系,用于系统开发的管理,2023/3/21,44,调
16、度程序,GUI,计划程序,注册登记,更新,表现系统内部的静态结构,说明一个物理系统由哪些组件构成,它们之间有什么联系,通过什么接口互相依赖,协同工作,2023/3/21,45,建立组件图的步骤:确定组件.考虑有关系统的组成管理,软件的重用和物理节点的配置等因素,把关系密切的可执行程序和对象库分别归为组件,找出相应的对象类,接口等模型元素对组件加上必要的构造型,说明组件的性质.确定组件之间的联系.最常见的组件之间的联系是接口依赖.必要时把组件组织成包.绘制组件图,2023/3/21,46,animator.exeversion=5.0.1,一个软件产品的构成,2023/3/21,47,3 配置图
17、,2023/3/21,48,3.1 配置图的用途,描述了系统不同运行过程的配置以及建立在其上的软件的执行过程配置图上的节点代表了计算资源的运行时的物理对象，通常具有内存和处理能力。节点可能具有用来辨别各种资源的构造型，如CPU,设备和内存等配置图描述了软件模块在企业的分布情况,2023/3/21,49,3.2 节点及其表示,节点(Node)是存在于运行期间的系统的物理元素节点代表计算机资源,通常为处理器或其它硬件设备,系统的组件可以配置在节点上节点的表示:三维立方体,2023/3/21,50,egb_server,Server:backupremote administration only,
18、sales,DeployPos.exeContacts.exe,节点的简单名字,节点路径名字,节点的标记值,扩充节点,2023/3/21,51,节点和类一样可以区分型和实例节点的型代表计算资源的不同类型,节点的实例代表特定的具体的计算机资源如:“客户机”是一个节点的型,表示一个系统中的用户使用的PC机,而“我的PC机:客户机”是“客户机”的一个实例.节点的实例必须有名字,后面跟冒号和所属的节点型的名字.节点实例名必须带有下划线.组件和对象可以驻留在节点实例上,而且可以从一个节点向另一个节点转移,节点执行组件,2023/3/21,52,x,V,w,Z,x,V,节点1,节点2,2023/3/21,
19、53,3.3 节点的联系,节点与节点之间通过物理连接(connection)发生联系,物理连接如网络,总线等节点与节点,节点与组件之间存在着多种类型的联系,包括关联(通信联系)和依赖(支持联系,成为联系),2023/3/21,54,通信联系是节点之间通信路径或连接的模型,它是节点之间的一种关联表示:用一条实线连接两个节点,在线上可以加构造型以表达节点间的通信路径或连接的性质,2023/3/21,55,触摸屏,服务器,控制台,RAID设备,2023/3/21,56,支持联系节点与组件或对象之间的依赖联系如果一个节点与一个组件或对象存在着支持联系,说明该节点上驻留着该组件或对象.该组件或对象能够在
20、该节点上执行.,组件,节点,构造型可省略,也表示支持联系,支持联系可以用标记值location说明其性质,2023/3/21,57,成为联系组件与组件,组件与对象,对象与对象之间的依赖联系它是组件或对象在节点之间的迁移的模型,组件,对象,组件,对象,组件,对象,组件,对象,什么时候发生迁移,迁移后状态和角色发生了变化,2023/3/21,58,2023/3/21,59,3.4 配置图的应用,构成元素节点,节点之间的联系,组件,节点与组件的联系,组件与组件的联系并非所有的系统都需要建立配置图,如单机运行系统,就没必要配置建模就是把软件系统在网络上的运行方式模型化配置图表示分布式系统的软件组件与硬
21、件之间的关系,表达的是系统运行的结构也可以用于建立业务模型,此时的运行系统就是业务的组织结构和资源(人力/设备等),2023/3/21,60,2023/3/21,UML 再回首,2023/3/21,62,1.为什么需要UML,面向对象方法学的出现从面向对象的设计到面向对象的分析多种面向对象分析与设计方法学并存需要一种统一的,标准的分析方法,2023/3/21,63,2.什么是UML,UML(统一建模语言)是为软件系统的制品进行详述（specifying）、可视化（visualizing）、构造（constructing）、文档化（documenting）的一种语言。它同样适用于商业模块和其他非
22、软件系统。,2023/3/21,64,3.利用UML如何建模,UML将软件的体系结构分解为五个不同的侧面，称为视图(view)。分别是：用例视图（Use case view）设计视图(design view)进程视图（process view）实现视图(implementation view)分布视图(deployment view)设计视图和进程视图又可被统一称为逻辑视图(logical view)。,2023/3/21,65,4 UML中有哪些模型图,模型图是UML基本模型元素及其关系的组合,由此便产生了9种UML模型图。它们是:类图对象图用例图序列图协同图状态图活动图组件图配置图,202
23、3/3/21,66,5 视图与模型图的关系如何,视图由一种或多种模型图(diagram)构成模型图描述了构成相应视图的基本模型元素（element）及它们之间的相互关系。,2023/3/21,67,6 视图中包含哪些模型图,用例视图用例图交互图状态图活动图逻辑视图类图对象图交互图状态图活动图,2023/3/21,68,6 视图中包含哪些模型图,实现视图部件图交互图状态图活动图分布视图交互图状态图活动图,2023/3/21,69,7 模型图回顾:用例图,什么是用例在UML里，软件系统的功能和其代表的动态行为是用用例来建模的。用例代表系统为响应系统作用者引发的一个事件而执行的一系列的处理，而且这处
24、理应该为系统作用者产生一种可见的价值。用例图Actor:不仅指外部用户,也可指外部系统,Actor之间可以有泛化关系Use Case:泛化,包含,扩展关系Actor和Use Case之间存在关联关系(可以有向,双向)注意Specification,2023/3/21,70,2023/3/21,71,7 模型图回顾:交互图(1),对象之间的合作是通过对象之间的消息的传递实现的。对象之间的合作在UML里被称为交互。交互是为达某一目的而在一组对象之间进行消息交换的行为。交互可以对软件系统为实现某一任务而必须实施的动态行为进行建模。交互所包含的UML建模元素包括：对象消息,2023/3/21,72,7
25、 模型图回顾:交互图(2),序列图对象生存线控制焦点消息:消息的种类协同图序列图的变体构成对象Actor通路,2023/3/21,73,对象,1,对象,2:class,CallMe(String),destroy,调用,创建,销毁,返回,发送,2023/3/21,74,7 模型图回顾:状态图,状态图描述了一个对象或交互过程在它的生命周期中对一系列外界激励的所呈现出的不同状态以及它相应的响应和活动。构成状态：状态表示的是一个对象或交互过程中的一个特定阶段，满足了某一个条件，进行某项活动或等待某个事件的发生。状态对应一段有限的时间。状态对应于一组对象属性的值。子状态状态转换：简单状态转换：同一个对
26、象的两个状态之间的变化复杂状态转换：状态分解与状态同步,2023/3/21,75,7 模型图回顾:活动图,活动图是一种特殊形式的状态机，用于对计算流程和工作流程建模活动图中的状态表示计算过程中所处的各种状态，而不是普通对象的状态构成：Action State原子的或不可中断的，执行时间不考虑Activity states非原子运行动作流对象流泳道并发与同步,2023/3/21,76,2023/3/21,77,7 模型图回顾:类图,类的定义：类描述了一组对象的公共的结构和行为，类为对象规定了它们的结构和所能提供的服务（操作）类的表示：三部分类的关系：依赖、泛化、关联特殊类：接口，抽象类，参数化类
27、建模指南对象图：“快照”数据库建模：映射规则例外情况建模,2023/3/21,78,7 模型图回顾:包图,包的概念：包就是一种概念性的模型管理的图形工具包的表示包的嵌套包的构造型：如subsystemsystem包的联系依赖（主要为输入依赖）与泛化包图及其应用：模型管理，系统建模，开发跟踪,+窗口+表格事件处理,2023/3/21,79,领域,2023/3/21,80,7 模型图回顾:组件图与配置图,组件图配置图对象约束语言,2023/3/21,81,UML建模原则,UML的模型图不是UML语言成份（UML成员）的简单堆砌，它必须按特定的规则有机地组合而成，从而构成一个完备的UML模型图。完备
28、的UML模型图（well-formed UML diagram）必须在语义上是一致的，并且和一切和它相关的模型和谐地组合在一起。UML建模规则包括:名字：任何一个UML成员都必须包含一个名字作用域：UML成员所定义的内容起作用的上下文环境可见性：UML成员能被其它成员引用的方式完整性：UML成员之间互相联接的合法性和一致性。运行属性（execution）：UML成员在运行时的特性。完备的UML模型必须对以上的内容给出完整的解释,当用于软件系统的建造时，UML模型是必须是完备的,但是当模型在不同的视图中出现时,出于不同的交流侧重点,其表达可以是不完备的,2023/3/21,82,UML建模原则,建模的原则：在系统的开发过程中，模型可以：被省略：即模型本身是完备的，但在图上某些属性被隐藏起来，以减化表达。不完全：在设计过程中某些元素可以暂时不存在。不一致：在设计过程中暂不保证设计的完整性。目的:鼓励开发者在设计模型时把注意力放在某一特定时期内对分析设计活动最重要的问题上，而暂不迷恋于细节的完美，使模型逐步趋向完备。,2023/3/21,83,
