没有合适的资源?快使用搜索试试~ 我知道了~
93《理论计算机科学电子札记》44卷第4期(2001年)网址:http://www.elsevier.nl/locate/entcs/volume44.html14页在UML的约束语言OCL中加入图转换概念AndySchur?r1慕尼黑德国武装部队大学软件技术研究所Werner-Heisenberg-Weg 39,85577 Neubiberg,Germany摘要对象约束语言OCL是统一建模语言标准UML的一个组成部分。 它已被添加到UML中,作为一种基于逻辑的子语言,用于定义类不变式和操作的前置/后置条件。OCL与图转换语言PROGRES的一个子集,即所谓的路径表达式非常相似。这些路径表达式的用途与OCL类似。与OCL相反,路径表达式支持函数抽象,并支持用于条件迭代和传递闭包的额外操作符。此外,PROGRES还具有可视化查询子语言和精确的语义定义。根据我们开发PROGRES的经验,我们建议对OCL进行一些修改和扩展,作为其即将发布的2.0版本的建议。1介绍对象约束语言OCL是统一建模语言标准UML [8]的一个组成部分,用于基于逻辑定义类不变量或操作的前置和后置条件[19]。在当前的形式中,OCL遇到了与UML标准的许多部分相同的问题:它既没有精确的静态语义,也没有精确的动态语义定义。这就是为什么研究人员现在积极地改进和重新设计OCL的各个部分,以促进UML 2.0定义过程的原因[3,13]。这是最近开始的一个研究项目的目的,应用我们的经验与发展的图形转换语言PROGRES的OCL。PROGRES是一种可视化的、可执行的规范语言,它结合了(1)UML类图的一个子集,用于定义图模式1电子邮件:Andy. unibw-muenchen.de2000年1月,出版社dbyElsevierScienceB。 V. 在CCBY-NC-ND许可下开放访问。斯丘尔94(2)用于定义对象结构管理的图形转换规则,以及(3)用于定义完整性约束、前置/后置条件和图形查询的OCL类路径表达式[17]。PROGRES路径表达式子语言在以下属性方面与OCL类似• 它与类UML的类图和对象操纵操作的关系与OCL相同。• 它区分了部分定义和始终定义的表达式,以及单个对象和集合返回路径表达式。• 它还将布尔值、字符串、整数等的表达式与用于沿关联导航的路径表达式相结合。另一方面,在PROGRES路径表达式和OCL之间存在一长串显著的(i) 我们的路径表达式有一组定义良好的类型检查规则,表示为谓词逻辑公式。(ii) 此外,PROGRES具有基于非单调推理和定点理论的精确定义的语义(iii) 它的动态语义定义区分了返回未定义结果nil的终止计算和具有未知结果的非终止计算。(iv) 部分定义的布尔表达式,导致了OCL中三值逻辑的引入,是不允许的;这是因为我们的经验,三值逻辑经常导致相当意外的结果。(v) 支持普通表达式和路径表达式(图上的派生二元关系)的函数抽象(vi) 用于定义默认值的运算符(对于部分定义的子对象),建立传递闭包,条件迭代等,可以添加到OCL中。(vii) PROGRES的类OCL文本路径表达子语言由与UML协作图的结构部分密切相关的图形子语言来补充。(viii) 不支持属性关联、n元关联、包和序列,尽管PROGRES用户经常抱怨缺少这些OCL特性。(ix) 一个集成的编程环境是可用的,包括一个语法指导的编辑器,一个解析器,一个增量类型检查器,一个解释器,和一个C编译器。因此,开始一个研究项目是相当诱人的,该项目基于我们对或多或少未知的规范语言PROGRES的经验来完善广泛传播的OCL标准。第一批结果涉及斯丘尔95OCL的更精细类型系统的定义,解决了[2]中未解决的一些问题-在[16]中给出,这里不再重复。本文件的目的是讨论上述第(六)和第(七)下面的第2节首先介绍一个从[11]中采用的运行示例。它使用了一个从根本上简化的UML类图和协作图(快照)的Meta模型来展示OCL的典型困难,并定义了适当的不变量。第3节显示了从PROGRES中提取的一些附加运算符如何大大简化了第2节中OCL约束的构造。此外,本节介绍了OCL表达式的函数抽象概念,并讨论了有关递归定义的OCL表达式的语义的一些问题。第4节讨论了本文的第二个主题,可视化约束定义子语言的开发。 它从[1]和[11]中发表的与OCL相关的视觉约束定义语言的简短调查开始。基于[1]中提出的图变换相关工作和PROGRES的相关图形约束定义子语言,我们讨论了基于协作图的约束可视化定义以及定义图形否定结构语义的不同可能性。最后,第5节总结了所提出的建议,并概述了这一领域的未来活动。2运行示例第一个将文本OCL约束与图形约束定义子语言混合的提案之一的开发人员在[11]中使用了UML Meta模型的简化片段作为他的运行示例。UML类图Meta模型的一部分和其协作图模型满足以下要求:• 所有熟悉UML或其前身的读者都可以理解所描述的示例及其相关约束。• 毫无疑问,OCL对所需约束的定义所提出的问题具有实际意义。• 在简化的形式下,这个例子仍然足够小,可以用在像这样的简短论文中。• 所选示例突出了当前有效的OCL定义存在的许多问题。我们采用了这个例子,并对图1所示的Meta类图做了一些小的修改。首先,成对的关联-结束-名称被替换为单个关联(结束)名称。 这是由于事实上,所有需要的OCL表达式都只能沿着一个方向导航,所关注的协会。此外,我们重新引入了Meta类(模型)元素和实例,以减少所需的dif的数量斯丘尔96例如链路对象Meta关联。接下来,我们决定二进制链接不是角色的实例,而是二进制关联的实例。最后,我们添加了包之间的导入关系导入以及Meta关联conformsTo和visible,作为派生关系的递归定义的示例。具有/conformsTo超类类源靶/可见AssocAssoc进口的类图目标源快照的Meta类图(对象图)具有图1.一、运行示例,一个简化的UML Meta模型。下面的图2呈现了图1的Meta类图的实例的示例。它的上半部分包含一个包Q,其中引入了三个类(A,B和C)和它们之间的两个关联(a和b)关联的三角形类图第二Q. 2它使用导入的类A派生两个新的子类D和B。因此,对于使用简单类名B而不是限定类名的包客户端,新类P::B隐藏了导入的类Q::B::B引用一个需要的类。图2的底部给出了一个快照(协作图)的例子,它与相关包P的类图(包括包Q中类图的可见部分)一致。它使用关联a的链接(实例)连接类C的实例o1类D的实例o2,它是所需目标类A的子类。通常需要的约束,保证一致性的一个单元-用所选包(本例中为P)的类图拍摄的是:2我们假设图2中显示的所有元素都具有公共可见性。快照包类元件斯丘尔97一B<<进口>>PBDQ一C问:AB类级别实例级o 1:C一o 1:D图二、UML类图和一致快照的示例(i) 快照的任何对象都是类的实例,类是所考虑的包P的可见组件。(ii) 快照的任何链接都是关联的实例,该关联是所考虑的包P的可见组件。(iii) 快照的任何(二进制)链接都有一个源(目标)对象,该对象是一个类的实例,该类符合其关联的源(目标)类。(iv) 一个类或关联对于一个包P是可见的,如果它是P的一个组件,或者是另一个包Q的一个组件,而包P通过导入依赖关系直接或间接地导入了这个组件。(v) 一个类D符合另一个类A,如果D = A,或者如果存在另一个类B,使得D符合B,并且B是A的直接子类。使用OCL 1.3版本精确定义这些限制是不可能的,原因如下:当前有效的OCL标准既没有定义函数抽象,也没有定义两个派生关系visible和conformsTo所需的传递闭包运算符。因此,目前的做法是假设函数抽象的存在,并使用递归定义的函数(参见。UML标准Meta模型的相关断言[8])。使用OCL的这种扩展,可以定义上面列出的约束。图3从主要约束(i)、(ii)和(iii)的OCL表达式开始。第一个OCL表达式开始于快照类的实例,通过一个of链接导航到所有可见的斯丘尔98(1) 上下文快照inv:self. of. visible。oclAsType(Class)->includesAll(self.has.oclAsType(Object).class)(2) 上下文快照inv:self. of. visible。oclAsType(AsType)->includesAll(self.has.oclAsType(Link). asclay)(3) context快照inv:self. has。oclAsType(Link)-> forAll(l|l.source.class.conformsTo->includes(l. aslog.source)和l.target.class.conformsTo->includes(l.assoc.class))(4) context包inv:self.visible = P.has->union(P.import.visible)->asSet(self.visible(N)=if self.has->select(Name = N)->notEmpty则self.has->select(Name = N)其他self.import.visible(N)endif(5) contextClassinv:self.conformsTo =self.superclass.conformsTo->including(self)->asSet图三.快照约束的OCL定义。的关注包。然后,它要求对象的结果集包括所考虑的快照的对象的所有类第二个OCL表达式具有类似的形式。它要求所考虑的快照实例自身的所有链接的关联对于其相关包自身是可见的。图3的第三个OCL表达式处理上面的要求(iii)它检索所考虑的快照的所有Link实例,并且对于该集合的所有元素l,要求其关联的源(目标)的类是与l的源(目标)的类一致的所有类的集合的元素。下面带label(iv)的OCL表达式介绍了上面使用的可见派生关系的简单其递归定义的语义--计算关联导入的传递闭包,然后遍历关联--具有或多或少精确定义的语义,只要在所考虑的类图中没有导入精确的OCL语义定义如何处理循环导入关系是一个悬而未决的问题。按照一些演绎数据库系统编程语言的思路,衍生关系。在这种情况下,周期上任何包的任何组件对于该周期上的所有包都是可见的。另一方面,遵循斯丘尔99导入依赖循环中的包。我们将在下面的第4节中看到PROGRES如何解决这个问题,以及OCL 2.0版如何通过引入一个新的传递闭包运算符来解决这个问题。下面的表达式(应用于一个给定的包,并以某个名称N作为参数,它会找到一个可见的组件,名称为N.例如,应用于图2的具有参数“B“的包P,这个表达式为我们在第4节中引入另一个OCL操作符提供了动机,它克服了图3所示的子表达式self.has->select(Name = N)为了完整性的原因,添加了图3的具有标签(v)的最后一个表达式。它引入了仍然缺失的派生关系conformsTo的定义。如果我们把类图看作是循环的超类关系,那么它的语义也就不明确了。请注意,这种派生关系对于定义禁止类层次结构中循环的OCL约束是必要的。因此,需要像conformsTo这样的派生关系来排除conformsTo的语义没有精确定义的情况3从PROGRES本节提出了OCL 1.3/1.4版的一些扩展,解决了第2节中报告的派生关系定义的一些困难。首先,在OCL中加入了函数抽象的概念这允许封装和重用导航表达式E,它从类SC的对象开始,返回类TC的单个定义良好的对象,或者这个类的可能未定义的对象,或者这个类的对象的集合(集合,包,序列)。这样的功能抽象可以具有如图4所示的附加参数。图4的具有标签(4)、(4 ')和(5)的函数第一个函数通过使用新的传递闭包运算符*解决了前面提到的循环导入关系的终止问题。该操作符的实现它被翻译成标准的OCL,或者更准确地说,被翻译成OCL 1.3版,以及许多文档中使用的模糊定义的函数抽象,如图5所示。请注意,最近添加的let-construct可能与预期的具体语法一起使用,而不是[8]中定义的语法,它省略了关键字in后面的表达式。此外,它可能在使用时考虑到了预期的语义,即。为3 对 于 单 个 结 果 对 象 , 结果 参 数类 型 表示 为TC ? 对 于可 能 未定 义的结 果对 象 ,以 及set/bag/sequence(TC),用于TC类对象的集合、包和序列。斯丘尔100(4)functionvisible:Package ->set(Element)=self.import*.has->asSetend(为self. 尝试has->select(Name = N)其他import.visible(N)endtry->unique端(4”)函数visible(N:string):Package -> Element?为self. 回路进口退出并返回has->select(Name = N)endloop -> unique端(5)functionconformsTo:Class ->set(Class)=self.superclass*->asSetend图四、使用新的运算符修改了OCL表达式给子表达式赋值,而不是给参数化函数赋值。从我们的观点来看,不同的句法结构应该用于这两个不同的目的。图5中定义的第一个函数是递归定义的pClosure运算符,它使用一个额外的集值参数来跟踪所有已经访问过的对象和。它从集合S中排除这些对象,集合S是它递归调用的输入。第二个带label(4 ')的函数try-运算符的求值从它的第一个分支has->select(Name = N)的求值开始。此分支尝试返回一个元素,该元素具有所需的名称,属于目前的包。当且 仅 当 第 一 个 分 支 的 求 值 失 败 ( 返 回 空 集 ) , 则 第 二 个 分 支import.visible(N)被求值,它确定当前包的所有导入包,并要求这些包提供具有所需名称的可见元素。如果我们假设递归函数定义是“天真的”从左到右和深度优先的求值,那么我们又会遇到终止的问题。因此,我们需要第三个新的运算符loop,它支持条件迭代(带循环检查)。带label(4”)的函数声明使用此运算符。它将子表达式导入应用于当前对象集的所有对象(迭代地),对于这些对象,子表达式的计算已经->select(Name = N)失败。关于try- and-loop-操作符语义的更多细节,读者可以参考图5。它的方程(2)将try-算子转化为标准OCL,而它的方程(3a)、(3b)和(3c)引入了不同版本的循环算子。第一个迭代子表达式P1的应用,直到子表达式P2返回一个非空集。这套斯丘尔101(1) X.p* = X.pClosure(X)X.pClosure(Y)=令 S:. = X.p->excludeAll(Y)inS->collect(pClosure(S->union(Y)->asSet endlet(2) X. tryP1else P2endtry =ifX.P1->notempty then X.P1else X.P2endif(3a)X. 循环P1直到 P2结束循环 =X.(select(P2->isEmpty)->collect(P1))* ->collect(P2)如果P2是返回一组对象(3b)X. 循环P1直到 P2结束循环 =X.(select(notP2)->collect(P1))* ->select(P2)if P2 is a Boolean OCL expression(3c)X. loopPendloop =X.P*->select(P->isEmpty)图五.标准OCL中新运算符的翻译。是整个表达式的结果集第二个版本允许布尔子表达式P2。它迭代子表达式P1对所有不满足条件P2的对象的应用。它返回所有满足条件P2的访问对象,包括一般情况下的start对象。循环运算符的第三个版本只是一个简写,用于经常需要的情况,即P1和P2是相同的表达式。表达式loop Pendloop返回所有被P的传递闭包访问的对象,对于这些对象,P的应用返回空集。应用于一个P-循环上的对象,P endloop计算空的对象集.图4中的函数(unique运算符返回非单例集合的未定义结果,否则返回所考虑集合的单个元素。作为一个conse- quence两个版本的功能可见的结果类型元素?对于一个可能未定义的结果对象的类Element。4一种可视化约束定义子语言使用上一节中精确定义的派生关系visible和conformsTo,我们将讨论如何使图3中的约束人们常说,视觉表达比文本表达更具可读性。因此,UML主要是可视化建模子语言的集合,而OCL是一种纯文本的子语言。因此,已经有人提出了一些建议,向OCL添加我们所知道的第一个此类建议建议使用欧拉圆[6]或维恩图[18]的变体,称为蜘蛛图[11]。下面的图6将图3的约束(i)的定义显示为蜘蛛图。它要求斯丘尔102:类:对象自我:包装:阿斯彭:链接自我:包装快照包的具有具有对象类类*任何快照与单个包4相关(通过一个of-链接),使得对于所考虑的快照的所有对象,以下条件成立5:这些对象的类实例集是属于相关包的类实例集的子集。见图6。 使用蜘蛛图进行可视化约束定义。通常,图6的蜘蛛图是否比图3的文本OCL版本更具可读性还是相反,这是一个品味和教育问题。但是很明显,蜘蛛将另一类图引入到UML中。因此,在[1]中提出了另一个建议,即使用这是一种用于相同目的的协作图的变体。这些协作图被解释为所谓的代数图变换方法的图模式,如图变换系统AGG [5]所实现的。(1)上下文快照inv:(2)上下文快照inv:的具有类的具有Assoc可见翻译:可见的自我oclAsType(Class)-> includesAll(S.has. oclAsType(Object).class)可见翻译:可见的自我oclAsType(AsType)-> includesAll(S.has.oclAsType(Link). asclay)图7.第一次会议。视觉约束定义为协作图。图7给出了图3中前两个OCL约束的定义,它们在图的底部重复图纸必须是[4]蜘蛛图中的点表示存在量化。[5]蜘蛛图中的星表示万有量化。斯丘尔103:对象自我:对象l:链接内容如下。对于任何快照对象,自检相关包和对象(链接)实例及其相关类(Asynchronous)实例的所有组合。所描绘的图形模式的非粗体部分的这些匹配必须可扩展为包括给定图形模式的粗体部分的匹配。在这种情况下,粗体部分要求在匹配的Class(Asynchronous)实例和匹配的Package实例之间存在派生的可见关系。图8显示了协作约束图的一个更详细的示例。它等同于在图8的底部重复的图3的约束(3)它要求源和目标对象之间的链接,这是某个源和某个目标Class之间的Assignment(iation)的实例,源(目标)对象的Class符合Assignment(iation)的源(目标)Class。(3)上下文快照inv:源目标符合条件符合条件Assoc具有类源具有目标类具有翻译:self. has. oclAsType(链接)->forAll(l| l.source.class.conformsTo-> includes(l. assistance.source)和l.target.class.conformsTo->includes(l.assoc.class))见图8。一个(更)复杂的视觉约束。[1]中提出的使用协作图的变体来定义约束的建议给定图的“常规”部分必须可扩展到其常规部分加上其粗体部分的匹配,并且不得扩展到其常规部分的匹配。大部分(加上粗体部分)加上虚线部分。这是图转换系统AGG使用的负子图模式的语义。根据我们在图形转换语言PROGRES中使用否定的经验,这种对否定子模式的解释在某些情况下似乎是非直觉的。例如,图9中可见6它确定给定两个的所有匹配6基于图形模式的派生关系的可视化规范的思想,:类:类:阿斯彭:类:类斯丘尔104具有具有可见(N)重命名姓名= N姓名#N姓名= N输出:元素:元素:元素:包装in:包装functionvisible(N:string):Package ->set(Element)=进口或图9.第九条。视觉约束的函数抽象和否定子图,其中distinguishedin Package匹配visible的主输入参数。它返回标记为out的节点(对象)的所有计算匹配的所有Element实例的集合。应用于一个给定的包,它返回自己的组件和所需的名称,或者如果满足某些条件,则返回其他包的一些可见组件和正确的名称。函数visible的右侧子图的AGG语义排除了这样的情况,即所考虑的包包含具有所需名称的元素,并且它同时用正确的名称重命名导入的元素。这不是我们想要的条件我们想要表达的是这样一个事实:如果P导入Q,并且P既不包含同名元素,也不将导入的元素重命名为不同的名称,则来自包Q的Name= N的元素在包P中可见。总而言之,PROGRES要求所有节点和边的匹配具有规则边界的逻辑示意图可能无法扩展为匹配所有节点以及具有规则边界的边加上其具有虚线边界的节点的非空子集加上它们的相邻边。另一方面,AGG要求具有规则边界的图的所有节点和边的匹配可以不能扩展到匹配所有具有规则边界的节点和边,所有的部分都有虚线的边界。 请注意,函数visible的预期定义可以在代数图变换方法中通过为图9的每个虚线元素节点及其相邻边缘构造一个(负)扩展来表达。 在本例中,一种虚线图形元素不再足以写下所需的要求。需 要 进 一 步 的 讨 论 和 实 验 来 确 定 在 大 多 数 情 况 下 AGG 变 体 或PROGRES变体是否如软件工程师所期望的那样工作,而软件工程师不是图形转换系统专家。从PROGRES中采用固定的开始节点in和固定的结果节点(集合)out7 PROGRES语法使用交叉节点和边代替虚线节点,表示否定的边in:包装具有输出:元素姓名= N斯丘尔1055结论和今后的工作在本文中,我们首先比较了UML的对象约束语言OCL与图转换语言PROGRES的类似子语言,并确定了当前版本的OCL标准的许多缺陷。基于我们开发PROGRES的经验,以及图转换社区中其他人将图转换概念合并到UML [12]或OCL [1]中的经验,我们提出了一些扩展OCL的建议。第一组建议的扩展涉及引入一些额外的运算符(用于构建传递闭包等),第二组涉及基于协作图添加可视约束子语言。据我们所知,根据与UML'2000会议相关的OCL研讨会的出席情况,到目前为止还没有提出添加类似操作符的其他建议。所提出的运算符unique是我们所知道的唯一例外。在OCL版本2.0 是上述八达通公司工作坊的其中一个讨论重点。关于增加视觉约束语言的建议,我们必须强调,我们的建议采用了[1]中提出的语法,但建议对否定进行不同的解释,并为视觉定义的约束增加了功能抽象的概念。尽管如此,我们必须承认,这是一个有争议的问题,无论是文本版本的OCL约束或其视觉对应物在这里提出更容易产生和理解。但是,只要没有编辑、分析和执行可视化定义的约束的工具,对这个主题进行更实质性的讨论就没有什么用处。在一定程度上,UMLCASE工具的所有协作图编辑器都可以用于编辑新的可视化约束,但是仍然缺少对分析和执行定义协作图的约束的适当支持。更糟糕的是,我们知道,到目前为止,还没有商业化的UMLCASE工具能够分析和执行标准的OCL表达式。它是其他研究小组正在进行的活动的主题[10,15],以设计和实现OCL 处理工具。我们的研究中心未来研究活动的主题是重新设计PROGRES路径表达式的语法,使其与未来的OCL标准定义兼容,同时保留其精确的静态和动态语义定义及其集成编程环境。引用[1] P. Bottoni,M.科赫,F。Parisi-Presicce和G.坦策OCL约束的一致性检查和可视化。在[7],第294-308页[2] T.克拉克UML静态模型的类型检查。在[9],第503-517页斯丘尔106[3] St. Cook,A. Kleppe和R. Mitchell等人关于OCL的大使宣言。技术报告,2000 年 。 http: www.trireme.com/amsterdam/manifesto-1-5.pdf ( 访 问 时间:2000年7月11日)。[4] H. Ehrig,G.恩格斯,H. J. Kreowski和G.罗森伯格,编辑。图文法和计算的图形转换手册:应用程序,语言和工具,第2卷。世界科学,新加坡,1999年。[5] C. Ermel,M. Rudolf和G.坦策AGG方法:语言和环境。在[4]中,第551-605页。1999年[6] L.欧拉 给你一个阿勒曼尼公主。 2(102-108),1761年。[7] A.埃文斯和圣肯特,编辑。统一建模语言(UML施普林格出版社[8] UML修订工作组。OMG统一建模语言规范v.1.3,文档ad/99-06-08。技术报告,对象管理组,2000年。http://www.omg.org/uml/(访问日期:2000年11月7日)。[9] R.法国和B.鲁普,编辑们。统一建模语言(UML施普林格出版社[10] H.胡斯曼湾Demuth和F.手指支持OCL的工具集的模块化架构。在[7],第278-293页[11] 圣肯特混合视觉和文本约束语言。在[9],第384-398页,1999中。[12] 联合Nickel,J.Niere,and A. Zndorf。富士环境。在Proc. ICSE 2000 -第22届软件工程国际会议,第742-745页。北京:人民出版社,2000年。[13] 精 确 的 UML 组 。 首 页 > 联 系 我 们 技 术 报 告 , 2000 年 。http://www.cs.york.ac.uk/puml/(访问日期:2000年7月11日)。[14] M. Richters和M.戈戈拉一个ocl的元模型在[9],第156[15] M. Richters和M.戈戈拉 验证UML模型和OCL约束。在9,第265[16] 还有你的... OCL(集合)表达式的新类型的检查规则. 2001年提交给2001年德国地理学会建模研讨会[17] 还有,安德里亚·S·J。温特,还有阿尔贝特·祖恩多夫。 PROGRES:语言和环境。在[4],第487-550页中。1999年[18] J. 维恩关于命题和推理的图解和机械表示腓麦格,123,1880。[19] J. Warmer和A.克莱珀OCL:对象约束语言-用UML精确建模。艾迪森·韦斯利,纽约,1999年。
下载后可阅读完整内容,剩余1页未读,立即下载
cpongm
- 粉丝: 4
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- zigbee-cluster-library-specification
- JSBSim Reference Manual
- c++校园超市商品信息管理系统课程设计说明书(含源代码) (2).pdf
- 建筑供配电系统相关课件.pptx
- 企业管理规章制度及管理模式.doc
- vb打开摄像头.doc
- 云计算-可信计算中认证协议改进方案.pdf
- [详细完整版]单片机编程4.ppt
- c语言常用算法.pdf
- c++经典程序代码大全.pdf
- 单片机数字时钟资料.doc
- 11项目管理前沿1.0.pptx
- 基于ssm的“魅力”繁峙宣传网站的设计与实现论文.doc
- 智慧交通综合解决方案.pptx
- 建筑防潮设计-PowerPointPresentati.pptx
- SPC统计过程控制程序.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功