23Spring_建模复习

UML中九种图的建模元素，以及九种模型图的作用，画法 (用例图 时序图 状态图为主)

UML（Unified Modeling Language）是一种通用的建模语言，用于描述和设计软件系统。在UML中，有九种不同类型的图，分别用于不同的建模目的，下面分别介绍它们的建模元素和作用。

1. 用例图（Use Case Diagram）：用于描述系统的功能需求和用户角色，主要包含用例（Use Case）、参与者（Actor）和关系（Relationship）三个建模元素。用例图的作用是帮助开发人员和客户之间共同理解系统的功能需求。

2. 活动图（Activity Diagram）：用于描述系统的业务流程和操作流程，主要包含活动（Activity）、控制流（Control Flow）和对象流（Object Flow）三个建模元素。活动图的作用是帮助开发人员和用户之间共同理解系统的业务流程。

3. 类图（Class Diagram）：用于描述系统的类和类之间的关系，主要包含类（Class）、接口（Interface）、关系（Relationship）等建模元素。类图的作用是帮助开发人员理解系统的静态结构和对象之间的关系。

4. 对象图（Object Diagram）：用于描述系统中的对象及其之间的关系，主要包含对象（Object）、关系（Relationship）等建模元素。对象图的作用是帮助开发人员理解系统中对象的实例化和关系。

5. 时序图（Sequence Diagram）：用于描述系统中对象之间的时间顺序关系，主要包含对象（Object）、生命线（Lifeline）、消息（Message）等建模元素。时序图的作用是帮助开发人员理解系统中对象之间的时间顺序关系。

6. 协作图（Collaboration Diagram）：用于描述系统中对象之间的协作关系，主要包含对象（Object）、消息（Message）等建模元素。协作图的作用是帮助开发人员理解系统中对象之间的协作关系。

7. 状态图（Statechart Diagram）：用于描述系统中对象的状态和状态之间的转换，主要包含状态（State）、转换（Transition）等建模元素。状态图的作用是帮助开发人员理解系统中对象的状态和状态之间的转换。

8. 部署图（Deployment Diagram）：用于描述系统中组件和节点之间的部署关系，主要包含节点（Node）、组件（Component）等建模元素。部署图的作用是帮助开发人员理解系统中组件和节点之间的部署关系。

9. 包图（Package Diagram）：用于描述系统的包和包之间的关系，主要包含包（Package）、依赖关系（Dependency）等建模元素。包图的作用是帮助开发人员理解系统包之间的关系。

用例图，类图，时序图(画用例图，其中某个功能的时序图)

在UML中，不同类型的图有不同的画法和符号，其中用例图、时序图和状态图是比较常用的三种图，下面分别介绍它们的画法：

1. 用例图：用例图的画法比较简单，用椭圆形表示用例，用人形图标表示参与者，用线条表示关系。用例图通常从左侧开始，用例向右侧展开，参与者位于用例图的左侧或上方。
   

2. 时序图：时序图的画法比较复杂，需要画出对象的生命线和消息的流向，通常从上往下画。生命线用竖线表示，消息用箭头表示，可以用实线、虚线等不同类型的线条表示不同类型的消息。
   

3. 状态图：状态图的画法比较简单，用圆角矩形表示状态，用箭头表示状态之间的转换，可以用实心、空心等不同类型的箭头表示不同类型的转换。状态图通常从上往下画，从初始状态开始，沿着状态之间的转换路径画出状态图。
   

4. 类图: UML类图是一种用于表示面向对象程序设计中的类、接口、关系等元素的图形化表示法 添加关系：使用箭头表示类或对象之间的关系。例如，使用实线箭头表示继承关系，使用虚线箭头表示关联关系。添加多重性：可以在关系箭头上添加多重性符号，以表示类或对象之间的关系的多重性。例如，* 表示多个，1 表示一个。

什么是用例, 那些图用来详细描述用例

在软件开发中，用例（Use Case）是一种描述系统功能和行为的技术。用例描述了系统的各种功能，以及这些功能是如何与系统的用户、角色和其他系统进行交互的。用例通常用于捕捉系统需求和用户需求，以便开发人员和系统分析师能够更好地理解系统的功能和行为，并在开发过程中进行测试和验证。

在UML中，用例可以通过用例图（Use Case Diagram）和详细用例规范（Detailed Use Case Specification）来表示和描述。用例图是一种UML图形表示方法，用于描述系统的用例和角色之间的关系。用例图通常包括用例、角色和系统边界等元素。用例规范则是一种文档，用于详细描述每个用例的场景、前置条件、后置条件、流程和其他相关信息。

除了用例图和用例规范，还有其他UML图形表示方法可以用来描述用例，例如：

1. 活动图（Activity Diagram）：用于描述用例场景中的活动和流程。

2. 时序图（Sequence Diagram）：用于描述用例场景中的交互和消息传递。

3. 协作图（Collaboration Diagram）：用于描述用例场景中的对象和它们之间的交互。

画出录音机的用例图, 顺序图

CPS系统

CPS系统指的是嵌入式计算机系统和物理系统之间的集成，它们共同工作以控制、监视和优化物理过程，如工业自动化、智能交通系统、智能制造和智能医疗系统等。CPS系统通常需要高度可靠性、实时性和安全性，因此需要采用特殊的设计方法和技术。

实时系统

实时系统指的是需要在严格的时间限制内完成任务的计算机系统。这些任务需要在特定的时间内产生正确的结果，否则可能会对系统的正常运行产生严重影响。实时系统可以分为硬实时系统和软实时系统。硬实时系统必须在规定的时间内完成任务，而软实时系统可以在某些情况下稍微超过规定的时间限制。

名词解释
时间约束（Timing constraint）：实时系统的任务具有一定的时间约束（截止时间）。根据截止时间，实时系统的实时性分为“硬实时”和“软实时”。硬实时是指应用的时间需求必须得到完全满足，否则就造成重大安全事故。
发布时间（Release Time）：作业变成为可执行的时间。如果所有的工作在系统开始执行时被释放，那么就认为没有发布时间。
截止时间（Deadline）：工作被要求执行完成的时间。如果截止时间是无限的，那么工作就没有最后期限。绝对截止时间等于发布时间加上相对截止时间。
响应时间（Response time）：作业从发布到执行完成的时间长度。

及时性（timeless）:实时系统中，动作必须在事件到达或者预期时间到达时开始执行，作出响应，在动作开始后的某个时刻必须完成,否则就会造成重大安全事故。
并发性（concurrency）：是指多个动作顺序链的同时执行。
可预测性（predictability）：系统的可预测性就是系统的响应特性所达到的可预知程度。
正确性和鲁棒性（correctness and robustness）：正确性表明一个系统总是运行正确。鲁棒性表明系统即使在遇到新的情况（不在计划中）下也是可靠的。因此必须警惕死锁，竞争以及其他异常情况。
实时操作系统特点： 及时性、可靠性（工业控制、武器发射等领域）

MDA模型驱动开发 (CIV-PIM-PSID）；（概念为主）

MDA模型驱动开发（Model Driven Architecture）是一种软件开发方法，它将模型作为软件系统的核心。MDA的核心思想是将系统的设计和实现从平台特定的细节中分离出来，以便更容易地实现跨平台的开发。在MDA中，开发人员首先定义系统的抽象模型，然后使用模型转换工具将其转换为特定平台的代码。这种方法可以提高开发效率和系统可维护性，并提高软件的质量和可重用性。

MDA 定义了三种模型：

• 计算独立模型（Computation-Independent Model，CIM）
  描述系统的需求和将在其中使用系统的业务上下文。此模型通常描述系统将用于做什么，而不描述如何实现系统。CIM 通常用业务语言或领域特定语言来表示。 用例图
• 平台独立模型（Platform-Independent Model，PIM）
  描述如何构造系统，而不涉及到用于实现模型的技术。此模型不描述用于为特定平台构建解决方案的机制。PIM 在由特定平台实现时可能是适当的，或者可能适合于多种平台上的实现。 类图、顺序图
• 平台特定模型（Platform-Specific Model，PSM）
  从特定平台的角度描述解决方案。其中包括如何实现 CIM 和如何在特定平台上完成该实现的细节。 如Spring、JSP模型

RM EDF调度机制

ROPES开发流程(需求分析、系统设计、系统实现)；

Rapid Object-Oriented Process Embedded System 用于嵌入式系统的快速面向对象过程

以下过程都建立在系统的模型之上，这些过程可以理解为同一模型的不同视图。要明白分析设计阶段用到的UML图。

1. 分析(analysis)阶段对所有可能的正确方案的本质特征进行识别。

   • 需求分析(requirements analysis)是从客户获取需求及把这些需求组织为容易理解的形式的过程。
   • 系统分析(system analysis)要构造定义更为严格的模型，并且以这些需求为基础，将系统的行为划分为机械组件、电子组件和软件组件。
   • 对象分析(Object Analysis)要给出重要的对象和类，以及它们的主要属性，前面的子阶段定义了系统要求具备的行为，这些需求由本阶段给出的对象结构予以满足。它还包括两个子阶段：
     • 结构对象分析(structural object analysis)以类和对象的形式标识对象分解的结构单元，同时建立对象分解的组织单元（包、节点和组件）以及这些元素之间的内在关系。
     • 行为对象分析(behavioral object analysis)为已识别的类定义必要的动态行为模型。

2. 设计(design)则在分析的结果中添加了一些元素，这些元素根据对某些判定准则的优化，定义了一份特定的解决方案。

   • 架构设计(architectural design)能够给出可部署软件系统的大尺度组织分解。
   • 机制设计(Mechanistic Design)：对对象间的协作具体化。
   • 详细设计(detailed design)定义类的结构和并对各个类的内部进行组织。

3. 转化(translation)阶段为设计创建一个可执行的、可部署的实现。（如将UML模型转化成源代码）

4. 测试(testing)要检查转化的结果是否与设计等价，并验证具体实现是否满足了分析阶段建立的正确性准则。

自动机的事件、迁移等内容理解；（结合实验）

MARTE语言的建模思想;

MARTE（Modeling and Analysis of Real-Time and Embedded systems）是UML的一个扩展语言，它特别针对实时和嵌入式系统的建模和分析进行了扩展。MARTE提供了一组新的建模元素和工具，用于描述实时和嵌入式系统的特性和行为，如并发、时间、资源、能耗等方面。MARTE还为UML提供了一些新的分析方法和工具，用于对实时和嵌入式系统进行性能分析、可靠性分析、功耗分析等。

MARTE语言的建模思想主要包括以下几个方面：

1. 面向模型的建模思想

MARTE语言采用基于模型的方法进行系统建模，将系统的各个方面都抽象成模型，包括功能、架构、行为、时间和资源等。每个模型都有其特定的目的和意义，并且可以在系统开发的不同阶段使用和分析。

2. 面向实时和嵌入式系统的建模思想

MARTE语言的建模思想是面向实时和嵌入式系统的，因此它包括对实时性、可靠性、安全性、资源约束等方面的建模和分析。这些方面在实时和嵌入式系统中都是至关重要的，因此MARTE语言的建模思想能够帮助开发人员更好地理解和分析系统的实时性能和约束条件。

3. 面向多视图和多层次的建模思想

MARTE语言的建模思想是面向多视图和多层次的，它允许开发人员从不同的视角和层次来描述和分析系统。这些视图和层次包括功能、架构、行为、时间和资源等，可以帮助开发人员更好地理解系统的不同方面，并且可以在不同的开发阶段进行使用和分析。

4. 面向分析和仿真的建模思想

MARTE语言的建模思想是面向分析和仿真的，它提供了一系列的分析和仿真工具，可以对系统的实时性能和资源利用率等方面进行分析和评估。这些工具可以帮助开发人员在系统设计的早期阶段发现和解决问题，并且可以提高系统的可靠性和效率。

总之，MARTE语言的建模思想是面向模型、实时和嵌入式系统、多视图和多层次、分析和仿真等方面的，它提供了一种统一的框架，可以帮助开发人员更好地进行系统级别的建模和分析。

MARTE中什么是refinement

在MARTE中，Refinement（细化）指的是从高层次的抽象模型到低层次的更具体的模型的转换过程。在这个过程中，高层次的抽象模型被逐步细化成更具体、更详细的模型，以便更好地描述系统的细节和行为。

MARTE中的Refinement可以分为两个方面：模型细化和执行细化。模型细化是指将高层次的模型转换为低层次的模型，以描述系统的结构和行为。执行细化是指将高层次的执行模型转换为低层次的执行模型，以支持系统的实时性和可靠性。

在MARTE中，Refinement是一个重要的概念，它使得开发人员可以在不同的抽象层次上进行建模和分析，从而更好地理解和描述系统的行为和性能。通过Refinement，开发人员可以逐步深入系统的细节，从而更好地理解和优化系统的性能和可靠性。

SysML与UML语言的区别？（从语义、语法和所面向建模场景方面进行区分）

SysML和UML都是基于图形化建模的语言，但它们在语义、语法和所面向建模场景方面存在一些区别。

1. 语义方面的区别：

SysML是一种专门用于系统工程的建模语言，它强调对系统的结构、行为和性能等方面进行建模。SysML包括对系统的需求、结构、行为和资源等方面的建模，而且可以支持多个视图和层次的建模。

UML则是一种通用的建模语言，主要用于软件系统的建模和设计。UML包括对软件系统的需求、结构、行为、交互和状态等方面的建模，而且也可以支持多个视图和层次的建模。

2. 语法方面的区别：

SysML是基于UML2.0的扩展，它保留了UML的核心概念和语法，同时还添加了一些新的元素和语法规则。SysML中包括了UML的类图、活动图、状态图、序列图等多种图形化表示法，并增加了需求图、块定义图、行为图等特定于系统工程的图。

3. 面向建模场景方面的区别：

SysML主要面向系统工程领域，支持对系统需求、结构、行为、资源等多个方面进行建模，以及进行系统级别的建模和分析。SysML常用于建模和设计复杂的物理系统、航空航天系统、汽车系统、医疗设备等。

UML则主要面向软件工程领域，支持对软件系统的需求、结构、行为、交互和状态等多个方面进行建模，以及进行软件级别的建模和分析。UML常用于建模和设计软件系统、网络应用系统、数据库系统等。

总之，SysML和UML在语义、语法和所面向建模场景方面存在一些区别。SysML主要面向系统工程领域，强调对系统的结构、行为和性能等方面进行建模；而UML则主要面向软件工程领域，强调对软件系统的需求、结构、行为、交互和状态等方面进行建模。

描述一下什么是模型驱动开发(MDD)

模型驱动开发（Model-Driven Development，MDD）是一种软件开发方法，它将建模作为主要活动，并通过自动生成代码的方式来实现软件开发。MDD是基于模型的软件开发方法之一，它提供了一种利用模型来描述软件系统的方法，从而可以帮助开发人员更好地理解和实现软件系统。

在MDD中，模型是软件系统的基础，它是对系统的结构、行为和功能等方面的抽象描述。模型通常使用图形化表示法（如UML、SysML等）来描述，包括用例图、类图、活动图、状态图等。这些图形化表示法可以帮助开发人员更好地理解和描述软件系统的各个方面。

在MDD中，模型不仅仅是一个文档或图形，而且它是软件开发的中心，所有的代码都是通过模型自动生成的。开发人员在模型中定义系统的结构、行为和功能等方面的信息，然后使用模型转换器将模型转换为代码。这些代码可以是各种编程语言（如Java、C++、Python等）的代码，也可以是配置文件、数据库脚本等。

MDD的优点包括：

1. 提高开发效率：通过模型自动生成代码，可以减少手工编写代码的时间和精力，从而提高开发效率。

2. 提高代码质量：由于代码是通过模型自动生成的，因此可以减少代码错误和缺陷，从而提高代码质量。

3. 改善软件维护性：由于模型是对系统的抽象描述，因此可以更好地理解和维护软件系统。

总之，模型驱动开发是一种基于模型的软件开发方法，它将模型作为软件开发的中心，通过自动生成代码的方式来实现软件开发，从而提高开发效率、代码质量和软件维护性。

自动机的事件，状态迁移等内容理解，

自动机是一种用于描述计算过程或系统行为的数学模型。它由一组状态和一组转移函数组成。每个状态代表系统或计算过程的一种状态，每个转移函数描述了从一种状态到另一种状态的转移过程。

自动机可以分为两种类型：有限自动机和无限自动机。有限自动机是指状态有限的自动机，而无限自动机则是状态无限的自动机。有限自动机通常用于描述具有固定数量的输入和输出的系统，而无限自动机通常用于描述具有无限数量输入和输出的系统，例如程序或操作系统。

在自动机中，事件是指输入到系统的信号或数据。状态迁移是指自动机从一种状态到另一种状态的转移过程。当自动机接收到一个事件时，它会根据当前状态和转移函数计算出下一个状态，并根据该状态执行相应的操作或输出。

在实际应用中，自动机常用于模拟计算机程序、控制系统、通信协议等。它们也可以用于验证系统的正确性和安全性，以及用于构建人工智能系统和机器学习模型。

顺序图的偏序

顺序图是一种UML图，用于描述对象之间的交互关系和消息传递顺序。在顺序图中，对象之间的交互被表示为一系列的消息传递，每个消息传递都有一个发送者和一个接收者。

顺序图中的偏序是指消息传递之间的先后顺序。如果两个消息传递之间存在偏序关系，意味着其中一个消息传递必须在另一个消息传递之前发生。这种偏序关系可以通过在顺序图中使用垂直的虚线来表示。

例如，假设有两个对象A和B之间的交互，其中A先发送了一条消息给B，然后B再发送一条消息给A。在顺序图中，可以使用两个垂直的虚线表示这两个消息传递之间的偏序关系。具体来说，第一个虚线表示A发送消息的时间，第二个虚线表示B发送消息的时间。这种偏序关系可以帮助开发人员更好地理解和描述对象之间的交互顺序，从而更好地设计和实现系统。

状态迁移时, 动作执行的顺序

在状态迁移时，动作的执行顺序可以分为两种情况：

1. 动作在状态迁移之前执行：这种情况下，动作会在状态迁移之前执行，然后才进行状态的迁移。这种情况通常称为”动作优先”，它意味着动作的执行对状态的迁移是有影响的。例如，在状态迁移之前，可能需要对一些变量进行计算或更新，这些计算或更新的结果可能会影响状态的迁移。

2. 动作在状态迁移之后执行：这种情况下，动作会在状态迁移之后执行。这种情况通常称为”状态优先”，它意味着状态的迁移对动作的执行是有影响的。例如，在状态迁移之后，可能需要执行一些操作来处理新状态的变化，这些操作可能会影响系统的行为或输出。

UML profile 用处, 和UML区别

UML Profile是一种UML扩展机制，它允许用户自定义UML元素和图形符号，以满足特定领域的需求或特定的开发过程。UML Profile提供了一种机制，使得用户可以在UML中创建新的元素、关系、图形符号、限制和约束等，从而扩展UML的能力和适应性。UML Profile可以用于各种领域，如嵌入式系统、Web应用、企业架构等。

与UML的区别在于，UML是一种通用的建模语言，它提供了一套标准化的符号和图形表示方法，用于描述软件系统的结构和行为。UML包括一些基本元素，如类、对象、接口、关系、活动、用例等，以及一些图形符号，如类图、活动图、时序图等。UML的目标是提供一种通用的建模语言，以便开发人员和系统工程师能够更好地理解和描述软件系统的结构和行为。

UML Profile则是在UML基础上进行扩展，它允许用户自定义UML元素和图形符号，以扩展UML的能力和适应性。UML Profile提供了一种机制，使得用户可以在UML中创建新的元素、关系、图形符号、限制和约束等，从而满足特定领域的需求或特定的开发过程。因此，UML Profile可以看作是UML的一个扩展，它提供了更多的建模元素和自定义能力，以适应不同的建模需求。

描述系统的执行过程 各次实验的理解(三选二)，考察查询语言

实验ATM中死锁, 危害