搜索

关于角色建模和语言的问题!

gecimao 发表于 2019-07-07 01:18 | 查看: | 回复:

  可选中1个或多个下面的关键词,搜索相关资料。也可直接点“搜索资料”搜索整个问题。

  推荐你《标准日本语》,这个网站下载的影片是和这本书配套的~希望你能好好学习

  统一建模语言(UML是 Unified Modeling Language的缩写)是用来对软件密集系统进行可视化建模的一种语言。UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。

  统一建模语言 (UML)是非专利的第三代建模和规约语言。 UML是在开发阶段,说明,可视化,构建和书写一个面向对象软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践,这些最佳实践在对大规模,复杂系统进行建模方面,特别是在软件架构层次已经被验证有效。

  UML作为一种模型语言,它使开发人员专注于建立产品的模型和结构,而不是选用什么程序语言和算法实现。当模型建立之后,模型可以被UML工具转化成指定的程序语言代码。

  公认的面向对象建模语言出现于70年代中期。从1989年到1994年,其数量从不到十种增加到了五十多种。在众多的建模语言中,语言的创造者努力推崇自己的产品,并在实践中不断完善。但是,OO方法的用户并不了解不同建模语言的优缺点及相互之间的差异,因而很难根据应用特点选择合适的建模语言,于是爆发了一场“方法大战”。90年代中,一批新方法出现了,其中最引人注目的是Booch 1993、OOSE和OMT-2等。

  Booch是面向对象方法最早的倡导者之一,他提出了面向对象软件工程的概念。1991年,他将以前面向Ada的工作扩展到整个面向对象设计领域。Booch 1993比较适合于系统的设计和构造。

  Rumbaugh等人提出了面向对象的建模技术(OMT)方法,采用了面向对象的概念,并引入各种独立于语言的表示符。这种方法用对象模型、动态模型、功能模型和用例模型,共同完成对整个系统的建模,所定义的概念和符号可用于软件开发的分析、设计和实现的全过程,软件开发人员不必在开发过程的不同阶段进行概念和符号的转换。OMT-2特别适用于分析和描述以数据为中心的信息系统。

  Jacobson于1994年提出了OOSE方法,其最大特点是面向用例(Use-Case),并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器,但用例贯穿于整个开发过程,包括对系统的测试和验证。OOSE比较适合支持商业工程和需求分析。

  此外,还有Coad/Yourdon方法,即著名的OOA/OOD,它是最早的面向对象的分析和设计方法之一。该方法简单、易学,适合于面向对象技术的初学者使用,但由于该方法在处理能力方面的局限,目前已很少使用。

  概括起来,首先,面对众多的建模语言,用户由于没有能力区别不同语言之间的差别,因此很难找到一种比较适合其应用特点的语言;其次,众多的建模语言实际上各有千秋;第三,虽然不同的建模语言大多类同,但仍存在某些细微的差别,极大地妨碍了用户之间的交流。因此在客观上,极有必要在精心比较不同的建模语言优缺点及总结面向对象技术应用实践的基础上,组织联合设计小组,根据应用需求,取其精华,去其糟粕,求同存异,统一建模语言。

  UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。

  面向对象技术和UML的发展过程可用上图来表示,标准建模语言的出现是其重要成果。在美国,截止1996年10月,UML获得了工业界、科技界和应用界的广泛支持,已有700多个公司表示支持采用UML作为建模语言。1996年底,UML已稳占面向对象技术市场的85%,成为可视化建模语言事实上的工业标准。1997年11月17日,OMG采纳UML 1.1作为基于面向对象技术的标准建模语言。UML代表了面向对象方法的软件开发技术的发展方向,具有巨大的市场前景,也具有重大的经济价值和国防价值。

  摘 要 最近由美国Rational公司发起并与其它十几家公司共同推出的“统一建模语言”UML在OO领域受到广泛的关注.文中首先介绍UML产生的背景及其主要内容,然后评论它对OO建模技术的积极影响以及可能存在的问题.UML是一种表达能力丰富的、强有力的建模语言;然而,目前还不能断定它将取代现有的各种面向对象的分析与设计方法.因为它只是一种建模语言,而不是一种方法;其复杂性可能成为它赢得大量用户的障碍.

  由于面向对象的分析与设计(OOA/OOD)方法的重要性日益突出,人们对它的研究、开发和应用的热情也在不断升高.在1989年,以专著、论文或技术报告等形式提出的OOA/OOD方法或OO建模语言有近10种,到1994年,其数量增加到50种以上.各种方法的出现都对OOA/OOD技术的研究与发展作出了或多或少的新贡献.这种“百花齐放”的繁荣局面表明面向对象的方法与技术已得到广泛的认可并成为当前的主流.然而多种方法的同时流行也带来一些问题:各种OOA和OOD方法所采用的概念既有许多共同部分也有一定的差异(例如许多方法在OO基本概念基础上各自提出了一些扩充概念,字面上相同的概念其语义解释也不尽相同);在表示符号、OOA模型及文档组织等方面差别则更为明显.这种情况往往使一些新用户在进行建模方法及工具的选择时感到难以决策,也不利于彼此之间的技术交流.

  鉴于这种情况,1994年同在美国Rational软件公司工作的G.Booch和J.Rumbaugh认为,应该把他们各自提出的方法(Booch方法〔1〕和OMT〔2〕)结合起来,形成一种统一方法.该年10月他们开始了这一工作,并于1995年10月公开发布了第一个版本,即Unified Method 0.8.1995年秋OOSE〔3〕的提出者I.Jacobson加入了Rational软件公司,于是也加入了这一行列.G.Booch,J.Rumbaugh和I.Jacobson共同认为,提出一种统一的建模语言有以下3个理由:第1,他们各自提出的方法在演化中已经有互相结合的趋向;第2,走向统一将带来市场方面的好处;第3,有助于改进他们各自的方法,以获得更多的学习者并解决一些以往在他们各自的方法不能很好解决的问题.

  为确定一套用于分析与设计的表示符号,他们遇到了一些需要权衡的问题.一是问题范围的界定.比如;是否应包括需求规约?(回答是,应部分地包括);是否应包括可视化编程语言?(回答为“否”).二是必须在表达能力和简单性之间作出折衷.表示法过于简单将使解决问题的能力受到限制,过于复杂则将使普通的开发者不知所措.三是在他们原先的3种方法基础上进行联合,也使他们必须顾忌对原有方法的改动大小;改动过大将引起老用户的混乱,沿用原先的东西则将失去作出改进并嬴得更多新用户的机会.从UML的文献中谈到的这些问题看,UML的提出不是单纯从学术和技术的立场寻找一种最合理的方案,而是必须考虑到与公司、老用户和原先各种方法有关的一些实际背景.

  不管怎样,他们作出了在这种背景下他们认为最好的权衡,于1996年6月和10月先后发布了UML 0.9和0.91版本.从此时起,“统一方法”改称为“统一建模语言” (unified modeling language).因为确切地讲,它并不是一种面向对象的建模方法,而是一种面向对象的建模语言.它只是给出一套用于建模的元素及表示符号并定义了它们的语义,而不是讲述如何进行系统建模.正如M.Fowler在专门介绍UML的著作〔4〕中指出的:“UML被称作建模语言,而不是一种方法.至少从原则上讲,大部分方法是由一种建模语言和一种过程共同组成的.其中建模语言是一种(以图形方式为主的)表示符号,用来表达人们的设计;过程则是对进行这种设计应采取哪些步骤所提出的建议.”M.Fowler的这本书是以UML1.0版本为背景写作的,G.Booch,I.Jacobson和J.Rumbaugh亲自为该书作序.这至少可以表明,该书对UML的这种总体评价是得到其缔造者认可的.

  按照UML文件的说法,“统一建模语言(UML)是一种用于软件系统制品规约的、可视化的构造及建档语言,也可用于业务建模以及其它非软件系统.”UML1.1提供了6份文件,均以UML伙伴组织中17家公司的名义联合印发.本节首先简略地介绍这些文件,下一节将对其中的UML表示法指南作较详细的介绍.

  (1) UML概要(UML Summary):是对UML的概括介绍,包括其动机、目标、范围、历史与现状.

  (2) UML语义(UML Semantics):定义了UML的语义.定义采用了形式化技术,但并不是完全形式化的规约.对语法结构给出了精确的规约,对其动态语义则是用自然语言描述的.UML的语法是一种与表示符号无关的抽象语法,它可以映射到不同的符号体系中.尽管没完全形式化,但其定义方式也颇为复杂:采用了4级元模型体系结构,文本的篇幅达到160余页.在该文件的2.2节介绍了模型的4个级别,即:

  ① 元-元模型(meta-metamodel):元模型的基础体系结构,定义一种说明元模型的语言.

  ② 元模型(metamodel):元-元模型的一个实例,定义一种说明模型的语言.

  ④ 用户对象(user object):模型的一个实例,定义一个特定的信息领域.

  对各级模型元素的定义方式是,首先给出它的抽象语法(采用UML的类图表示法描述元素之间的关系),然后给出其形式化规则(采用正文和对象约束语言),最后描述其语义(采用准确的正文).按这种方式总共定义了118个元素,划分到3个部分和9个包(package)中分别加以定义.

  (3) UML表示法指南(UML Notation Guide):该文件给出UML的可视化表示法,通过例子给出模型元素的图形表示符号,详见下一节.

  (4) 对象约束语言规约(Object Constraint Language Specification):该文件定义并介绍了一种对象约束语言(简称OCL),其用途是用来说明一些在图形化的系统模型中不能充分表达的建模信息.它是一种形式化的语言,但容易书写和阅读.作为一种建模语言,它并不表示实现方面的问题.就是说,它是用来对模型作详细说明的,而不是可编译执行的.

  (5) 用于软件工程对象过程的UML扩充(UML Extension for Objectory Process for Software Engineering):针对软件工程中的要求,定义了一些UML的扩充概念.例如,将模型分为Use Case模型、分析模型、设计模型和实现模型4种,对每一种扩充的模型概念给出其定义.它并未介绍面向对象的开发过程,也不讲在过程中如何运用UML.文件内容很短,只有5页.

  (6) 用于业务建模的UML扩充(UML Extension for Business Modeling):定义了用于业务建模的一些UML扩充概念,与上一个文件相似,只是它的扩充是针对一般业务处理建模,而不是对软件工程的.该文件也很短.

  该文件给出UML的可视化表示法,通过例子给出模型元素的图形表示符号.从系统模型这一级别上看,UML表示法由9种图构成,它们是:

  尽管UML文件称“UML表示法指南定义了表示法并提供了例子”,但确切的说法应该是:该文件对建模元素的表示法给出了一般的文字描述,其图形的画法是通过例子表现的,并没有给出一般的图示.本文大部分插图是参照M.Fowler的著作〔4〕的作法从一般意义上给出的.

  UML定义了一些在各种图中常用的元素,例如String(串)、Name(名)、Label(标签)、Keyword(关键词)、Expression(表达式)、Note(注释条)等,并给出它们的表示符号,例如关键词由一个被书名号括起的串表示,注释条用一个折起一角的长方形内的正文表示.在各种图中用来对一组模型元素打包的元素叫做“包”(Package),其表示法是用一个大的方框围起这组元素,并在角上用一个小框给出包的名字.

  此外,UML还定义了一些称作“扩充机制”的元素.这种元素可以附加到其它模型元素之上,将原有的建模元素特化成一种语义较特殊的新变种,或者表示出它们的某些细节.这些元素可以起到对表示法进行扩充或细化的作用,它们是:

  Constraint(约束):约束是模型元素之间的一种语义关系,它说明了某种条件和某些必须保持为真的命题.其表示法是在大括号{ }之间用一种工具能识别的语言(如UML提供的OCL)写出表示条件的正文串.

  Comment(注释):注释是写在注释条表示符号(折起一个角的长方形)之内的正文串.所使用的语言应易于人的理解,不必考虑被工具理解.

  Element Property(元素特征):用来显示模型元素的一些附带特征,如属性、关联、目标值等.其表示法是在大括号{ }内写出形式为 关键词=值 的正文串,多个串之间彼此用逗号隔开.

  Stereotype(版式):用来附加到其它模型元素之上,将原有的建模元素特化成一种语义较特殊的新变种.带有版式的建模元素可看作原先建模元素的一个子类,它在属性、关系等方面与原先的元素形式相同,但用途更为具体.板式是用书名号《 》括起来的关键字表示的.上述概念的表示法如图1所示.

  静态结构图包括类图(class diagram)和对象图(object diagram).“类图是静态结构模型的图形化示图.”“类图是(静态)声明的模型元素集合.”关于对象图,该文献中说道:“对象图是实例的一种图形,包括对象和数据的值,静态的对象图是类图的一个实例;它显示了在一个时间点上系统细节状态的一个快照”.该文献又指出:“对象图的用处是很有限的”,“工具没有必要支持独立形式的对象图.类图能包括对象,一个有对象而没有类的类图便是一个‘对象图’.不过这个术语对于刻画在各种方式下可能达到的特殊用法还是有用的”. 静态结构图中用到的各种建模元素的表示法如图2所示,以下分别加以介绍.

  Class(类):类是对具有相似的结构、行为和关系的一组对象的描述.UML对类提供了3种图形表示符.第1种是细节抑制方式,只在一个方框中给出类名;第2种是分析级细节方式,在上、中、下3栏分别给出类名、属性名与类型、操作名;第3种是实现级细节方式,给出更多的细节.

  Name Compartment(名字栏):定义了类符号的名字栏的书写规范.

  List Compartment(列表栏):定义了类符号的属性栏和操作栏的书写规范.

  Attribute(属性):规定了属性的写法,以及以下3种可见性符号:“+”表示public(公共),“#”表示protected(保护),“-”表示private(私有).

  Operation(操作):规定了操作的写法,采用与属性相同的3种可见性符号.

  Type vs. Implementation Class(类型与实现类):这是将版式关键词《type》或《implementation class》附加到类表示符号之上,并在属性栏和操作栏中给出属性与操作的定义细节而得到的两种较特殊的类元素.其中“类型”刻画一个对象可能采用然后又放弃的可变规则;“实现类”定义了在用一种语言实现时对象的物理数据结构与过程.以下7种表示符号都是用这种方式得到的.

  Interface(接口):接口是对一个类或其它实体(诸如包这样的大单位)的对外可见操作的说明,它不说明实体的结构.其表示法很像类符号,但没有属性栏;在名字栏中加关键词《interface》,在操作栏填写接口定义.

  Parameterized Class(Template)(参数化类,又称模板):它是带有一个或多个未绑定的形式参数的类,因此它定义一个类家族,将参数与一个实际值绑定便说明了其中一个类.参数化类的表示法是在类符号的右上角加一个虚线框,框内中说明各个形参的不同实现类型.

  Bound Element(绑定元素):它的作用是将模板的参数与实际的值联系(绑定).其表示法是用文字说明模板的参数值表.

  Utility(实用程序):以类的形式声明的一组全局变量与过程.它不是一种基本构造,而是一种编程便利设施.其表示法是在类符号的类名栏中标以关键字《utility》.

  Metaclass(元类):即类的类,它的实例是类.其表示法是在类名栏中加关键词《metaclass》.

  Class Pathname(类路径名):用以表示对一个类的引用.表示法是在引用这个类的地方(在其它包中)以符号“∷”指出被引用的类名.

  Importing a Package(引入一个包):表明在一个包中可以引用另一个包中的类.这是一种特殊的依赖(dependency)关系.其表示法是在dependency符号(虚箭头)上旁加关键字《import》.

  Object(对象):对象是类的一个特殊实例.UML给出的对象表示法是一个只有两栏的方框.名字栏填写对象(实例)名并指出它所属的类名.属性栏中给出每个属性的值.

  Composite Object(组合对象):由一些紧绑在一起的部分所构成的高层对象,它是组合类(composite class)的实例.用含有两栏的方框表示,在上栏填写组合对象名并指出其类名,在下栏画出它的各个部分对象.

  Association(关联):分为二元关联和多元关联,在以下的条目中分别介绍.

  Binary Association(二元关联):是两个类之间的关联(包括从一个类到它自身的关联这种特殊情况).其表示法是用一条实线连接两个类符号.这条线可根据绘图时的方便画成平直的、斜的或弯曲的.也可由若干段组成.线的端点与类符号相接的地方叫作关联端点,端点附近可以注明一些有用的信息,表明关联的不同情况(稍后介绍).整个关联也可以带有一些附加信息,包括:关联名(association name),通过这样的命名表明关联的作用;关联类(association class)符号,和普通的类符号相同,但必须附着在一个关联上,用于表明关联的属性与操作.这些东西都是任选的、非强制的.

  AssociationEnd(关联端点):关联端点不是独立的元素,它是关联的一部分,用于表明关联的一些细节内容.一部分细节内容通过在关联端点旁边附加一些字符或图形来表示,包括多重性(multiplicity)、有序性(ordering)、限制(qualifier)、角色名(rolename)、可变性(changeability)、可见性(visibility).另一些细节是通过关联线端点的不同形状来表示的,包括:开放形的箭头表示可导航性(navigability),即表示从关联一端的对象实例能够找到另一端与它关联的对象实例;空心的菱形箭头表示聚合(aggregation),即表示关联一端的对象实例是另一端对象实例的组成部分;实心的菱形箭头表示强形式的聚合关系,称作组装(composition).

  Multiplicity(多重性):在关联端点上标注数字(表示具体的数量)或“*”号(表示多个),以表明本端有多少个对象实例与另一端的对象实例相关联.

  Qualifier(限制),在关联的一端与类符号相接口的地方画一个矩形框,框中给出一些属性值指明关联另一端的对象符合什么条件才有资格与本端的对象关联,它是关联的一部分,而不是类的一部分.

  Association Class(关联类),用于表明一个关联带有类的特征(包括属性和操作),用普通的类符号表示,附着在关联线上.

  N-Ary Association(多元关联),3个以上的类之间的关联.其表示法是从一个菱形向各个相关联的类符号画出连接线.

  Composition(组装)按UML的说法,composition是aggregation的形式之一,它表示整体对部分有很强的拥有关系和相同的生存时间.其表示法是在关联线的端点加一个实心的菱形箭头.

  Link(链),链是关联的一个实例,表明两个对象之间的联系.其表示法是在两个对象实例之间画一条直线.

  Generalization(一般化):“是较为一般的元素和与之完全一致而又增加了更多信息的较为特殊元素之间的分类学关系.” 此概念和大部分OO技术文献中所讲的“继承关系”或“一般特殊关系”基本相同,不过,UML的generalization除用于表示类之间的关系外还用于包、Use Case和其它元素.表示法有两种方式.一种是共享方式,在一般元素的符号旁边画一个三角形,从三角形的底边引出一条连线,而这条连接有若干分枝,分别连向各个特殊元素;另一种是分散式,在一般元素的符号旁边画多个三角形,每个三角形的底边画出引向一个特殊元素的连线.在连线旁边可以加一个文字标注,叫做discriminator(鉴别器),标明是按什么进行分类的.

  Dependency(依赖):UML对dependency的语义是这样定义的:“指出两个(或多个)模型元素之间的语义关系.其涵义只涉及这些元素本身而不涉及他们的实例.它指出在这种依赖中对目标元素的一个改变可能需要对源元素的一个改变.”依赖有以下几种:

  trace-Trace:在不同的表意层次上表示同一概念的两个元素之间的一种历史连接.

  refine-Refinement:两个有映射(未必完全)关系的元素之间的历史或衍生连接.

  use-Usage:为了一个元素的正确实现或功能履行需要另一个元素出现.

  bind-Binding:将模板参数绑定到一个实际的值,以创建一个非参数化元素.

  依赖的表示法是在两个模型元素之间画一条带箭头的虚线,旁边可以标明该依赖关系属于以上哪一种,也可加一个名字.UML表示法指南在介绍dependency时没有谈到它与message(消息)的概念有什么联系和区别.UML的“消息”、“消息流”等概念分别用于顺序图和协作图(详见后文),而不用于类图.但是M.Fowler在文献〔4〕中作了这样的解释:“对类而言,dependency可以为如下几种理由而存在:一个类向其它类发送消息;一个类以其它类作为其数据的一部分;一个类提及其它类作为对一个操作的参数.”

  Derived Element(派生元素):派生元素是可以从其它元素计算出来的元素.尽管它没有增加语义信息,但是有了它可以更清楚或者更有利于设计.其表示法是在派生元素的名字前加一条斜线) Use Case图

  “use case图用于表现活动者与use case之间的关系.”“use case模型表现一个系统或一个类对于系统外部的交互者的功能.”UML定义了如下几种构成use case图的元素(如图3).

  Use Case:一个use case是一个系统或一个类提供的紧凑的功能单元,它是由系统与一个或多个外部交互者(即活动者)之间交换的消息序列以及系统执行的活动共同体现的.

  Use Case Relationship(use case关系),包括如下3种关系:communicates(通信),这是活动者与use case之间仅有的关系,是活动者对use case的参与;extends(延伸),从use case A到use case B的延伸关系表明B的实例(在延伸说明的特殊条件下)可能包含了在A中说明的行为;uses(使用):从A到B的使用关系表明A的实例也包括了在B中说明的行为.

  UML给出了两种形式的交互图(Interaction Diagram),一种叫顺序图,另一种叫协作图.它们基于相同的基本信息但强调不同的方面.顺序图(Sequence Diagram)展示按时间顺序排列出来的交互.特别是,它展示对象在其“生命线”上参加的交互和它们按时间顺序交换的消息.它不展示对象之间的关系.顺序图所表示的交互是一组在对象之间为产生所要求的操作或结果而进行合作时所交换的一组消息.顺序图有简单形式和详细形式两种画法,后一种画法与OOSE〔3〕等著作介绍的交互图大体一致——在水平方向展示各个参加交互的对象,垂直方向表示时间;整个平面显示各个对象之间进行交互的时间及空间关系,顺序图如图4所示.用于顺序图的建模元素有:

  Object Lifeline(对象生命线):一条垂直的虚线,用于展示对象在从创建到撤消的时间范围内所扮演的角色.

  Activation(活动期):展示对象直接地或通过其下级过程执行一个活动的时间段.

  Message(消息):消息是对象之间的一次通信,用于传送信息并期望发生某种活动.消息的接收是一种事件.

  Transition Time(过渡时间):消息发送或接收所用的时间.二者可能相同也可能不同.

  协作图(Collaboration Diagram)是UML所说的另一种交互图,它表示在一些对象之间组织的操作和它们之间的链.与顺序图不同的是,协作图表示的是对象角色之间的关系,而不表示时间顺序.协作图描绘了在特定上下文中一组相关对象之间的协作,以及这组对象为产生所要求的操作或结果而进行协作时所交换的一组消息.协作图的图形表示以对象为结点,结点之间既有表示消息的箭头连线,也有表示关联的连线种,分别表示调用、控制流和异步3种不同的消息,但仍有一些不能表示的情况,如阻塞(balking)和超时(time out)等,需要用一些进一步扩充的表示符号.协作图中使用的关联符号也包括多种不同的端点情况,如qualifier和composition等等.协作图如图5所示.

  状态图(Statechart Diagram)在UML中也称作状态机,它表现一个对象或一个交互在整个生存期内接受剌激时的状态序列以及它的反应与活动.它附属于一个类或一个方法.建立状态图所用的建模元素有:State(状态)、Composite State(复合状态)、Substate(子状态)、Event(事件)、Simple Transition(简单转换)、Complex Transition(复杂转换)、Nested State(嵌套状态)、Sending Message(发送消息)、Internal Transition(内部转换)等.状态图及其有关元素的表示法和现有的大部分OOA/OOD方法大同小异,这些不再详述.

  活动图(Activity Diagram)是状态图的变种,它的状态表示操作所执行的活动(activity),其转换(transition)是由操作的完成而触发的.它表示了一个过程本身的状态机,过程是对类中一个操作的实现.构成活动图的元素有:Action State(活动状态)、Decision(判断)、Swimlane(泳道,在图中画出来就象游泳池中的泳道,把各个活动组放在不同的泳道中以便更加清晰)、Action-Object Flow Relationship(活动-对象流关系,表示一个活动与有关对象之间的消息和输入/输出关系)、Control Icon(控制图符,表示信号的发送与接收)等.活动图如图6所示.

  实现图(Implementation Diagram)表现实现方面的问题,包括源代码结构和运行时的实现结构.实现图分为两种,一种是表示代码自身结构的成分图,另一种是表示运行时系统结构的展开图.

  成分图(Component Diagram)表示源代码、二进制代码及可执行代码等软件成分之间的依赖关系.各种软件模块在图?/ca

本文链接:http://robynlynne.com/duixiangjianmojishu/653.html
随机为您推荐歌词

联系我们 | 关于我们 | 网友投稿 | 版权声明 | 广告服务 | 站点统计 | 网站地图

版权声明:本站资源均来自互联网,如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

Copyright @ 2012-2013 织梦猫 版权所有  Powered by Dedecms 5.7
渝ICP备10013703号  

回顶部