郑州自动化软件讲解模型的内容和含义

       模型的内容

       1．语义和表示法

       模型包含两个主要方面：语义方面的信息（语义）和可视化的表达方法（表示法）。
 

       郑州软件公司认为语义方面用一套逻辑组件表达应用系统的含义，如类、关联、状态、用例和消息。语义模型元素携带了模型的含义，即它们表达了语义。语义建模元素用于代码生成、有效性验证、复杂度的度量等，其可视化的外观与大多数处理模型的工具无关。语义信息通常被称为模型。一个语义模型具有一个词法结构、一套高度形式化的规则和动态执行结构。这些方面通常分别加以描述（定义UML的文献即如此），但它们紧密相关，并且是同一模型的一部分。

       可视化的表达方式以可使人观察、测览和编辑的形式展示语义信息。表示方式元素携带了模型的可视化表达方式，即语义是用一种可被人直接理解的方式来表达的。它们并未增添新的语义，但用一种有用的方式对表达式加以组织，以强调模型的排列。因此它们对模型的理解起指导作用。表达式元素的语义来自于语义模型元素。但是，由于是由人来绘制模型图，所以表达式元素并不是完全来自于模型的逻辑元素。表达式元素的排列可能会表达出语义关系的另外含义，这些语义关系很不明显或模棱两可，以至于在模型中不能形式化地表达，但可给人启迪。

       2．上下文（语境）

        郑州apple软件开发认为模型自身是一个计算机系统的制品，被应用在一个给出了模型含义的大型语境中。这个包括模型的内部组织、整个开发过程中对每个模型的注释说明、一个默认值集合、创建和操纵模型的假定条件以及模型与其所处环境之间的关系。

       模型需要有内部组织，允许多个工作小组同时使用某个模型而不发生过多的相互牵涉。这种对模型的分解并不是语义方面所要求的——与一个被分解成意义前后连贯的多个包的模型相比，一个大的单块结构的模型所表达的信息可能会同样精确，因为组织单元的边界确定会使准确定义语义的工作复杂化，故这种单块模型表达的信息可能比包结构的模型表达得更精确。但是要想有效地工作于一个大的单块模型上的多个工作组不彼此相互妨害是不可能的。其次，单块模型没有适用于其他情况的可重用的单元。最后，对大模型的某些修改往往会引起意想不到的后果。如果模型被适当分解成具有良好接口的小的子系统，那么对其中一个小的、独立的单元所进行的修改所造成的后果可以跟踪确定。不管怎样，将大系统分解成由精心挑选的单元所构成的层次组织结构，是人类千百年来所发明的设计大系统的方法中最可靠的方法。

       郑州苹果软件开发认为模型捕获一个应用系统的语义信息，但还需记录模型自身开发过程中的各种信息，如某个类的设计者、过程的调试状态和对各类人员的使用权限的规定。这些信息至多是系统语义的外围信息，但对开发过程非常重要。因此，建立一个系统的模型必须综合考虑两方面。最简便的实现方法是将项目管理信息作为注释加人到语义模型中，即可以对模型元素用非建模语言进行任意描述。在UML中用文本字符串来表示注释。

       文本编辑器或测览器所使用的命令不是程序设计语言的一部分，同样，用于创建和修改模型的命令也不是建模语言语义的一部分。模型元素的属性没有默认值，在一个特定的模型中，它们均具有值。然而，对于实际的开发过程，人们要求建立与修改模型时无须详细说明有关的所有细节。默认值存在于建模语言和支持这种语言的建模工具的边界处。在建模工具所使用的创建模型的命令中，它们是真正的默认值，尽管它们可能会超过单个的建模工具并非用户所期望的那样成为建模工具所使用的通用语言。

       郑州android开发认为模型不是被孤立地建造和使用的，它们是模型所处的大环境中的一部分，这个大环境包括建模工具、建模语言和语言编译器、操作系统、计算机网络环境、系统具体实现方面的限制条件等。系统信息应该包括环境所有方面的信息。系统信息的一部分应被保存在模型中，即使这些信息不是语义信息，例如项目管理注释（在上面已经讨论过）、代码生成提示、模型的打包、编辑工具默认命令的设置。其他方面的信息应分别保存，如程序源代码和操作系统配置命令。即使是模型中的信息，对这些信息的解释也可以位于多个不同地方，包括建模语言、建模工具、代码生成器、编译器或命令语言等。本书用UMI一自身对模型进行解释。但是当进行系统的具体物理实现时，要用到其他用于解释的资源，这些资源对UML来说是不可见的。

       模型的合义

       一个模型是一个系统潜在配置的发生器，系统是它的范围或值。按照模型来进行系统配置是一种理想化的情况。然而，有时模型所要求的种种条件在现实中无法实现。模型还是对系统含义和结构的一般性说明。这种描述是模型的范围或含义。模型总是具有一定的抽象层次。它包含了系统中的最基本的成分而忽略了其他内容。对模型来说，有以下几方面需要考虑。

       1．抽象和具体

       郑州安卓软件开发认为模型包含了系统的基本成分而忽略了其他内容。哪些是基本内容哪些不是基本内容需要根据建模的目的来判定。这不是说要把模型所含信息的精度一分为二，即只有精确和不精确两种情况。可能会存在一系列表达精度不同但逐渐提高的模型。建模语言不是程序设计语言。建模语言所表达的内容可能很不精确，因为多余的详细内容与建模目的无关。具有不同精度级别的模型可应用于同一个项目的各个阶段。用于程序设计编码的模型要求必须与程序设计语言有关。典型的情况是，在早期分析阶段使用高层次的、表达精度低的模型。随着开发过程的深人，所用的模型越来越细化，最终所使用的模型包含了大量的细节内容，具有很高的精度。

       2．说明和实现

      郑州ios开发认为一个模型可以告诉我们“做什么”（说明），也可以告诉我们“一个功能是如何实现的——即怎么做”（实现）。建模时要注意区分这两方面。在花大量时间研究怎么做之前很重要的一点就是要正确分析出系统要做什么。建模的一个重要的侧面是对具体实现细节进行抽象。在说明和实现之间可能有一系列相关关系，其中在某层次中的说明就是对它上一层次的实现。

       3．阐述和举例

       模型主要是描述性的。模型所描述的是一个个实例，这些实例仅是作为例子才出现在模型中的。大部分实例仅在运行的一部分时间中才存在。有时，运行实例自身是对其他事物的描述。通常把这些混杂对象称为元模型（Metam。del）。更深一层次地看，认为任何事物不是描述性的就是实例性的，这种观点是不符合实际情况的。某一事物是实例还是描述不是孤立区分的，与观察角度有关，大部分事物都可以用多种角度来考察。

       4．解释的变更

        郑州plc开发认为用一种建模语言对模型可能会有多种的解释。可以定义语义变更点（semantic  varianon  Point）——可能会出现多种解释的地方——给每一个解释一个语义变更名，以便可以标识究竟使用了哪种解释。例如，Smalltalk语言的使用者要避免在系统实现模型中出现多重继承关系，因为Smalltalk语言不支持多重继承。而其他程序设计语言使用者可能会在模型中使用多重继承。语义变更点支持多种具体的实现过程。

       转载请注明出处：郑州知网软件  http://www.nwisdom.com