ESE模块 UML和SysML基础理论知识

书籍创建器
将本页添加到您的书籍中

书籍创建器
从您的书籍中删除本页

显示/修改书籍(0 页面)

帮助

DE | EN | CN

现代微控制器在芯片内部拥有比最初的个人电脑更强大的性能。这使得像C++这样的现代编程语言得以应用。通过这种方式，软件质量和开发速度可以显著提高。在个人电脑系统中，面向对象的编程语言早已经得到广泛应用。这种趋势也在微控制器中日益显现。

对许多人来说，面向对象是软件开发的一种范式，很难理解。即使你已经能够使用面向对象的编程语言如C++、JAVA或C#，也不一定意味着你会系统地应用面向对象的概念。

首先，让我们描述面向对象编程中最重要的概念。在文献中，这被称为抽象。这听起来比实际情况复杂。我们可以用简单的语言来解释这个概念：“我们给事物命名。”

这意味着，作为人类，我们通过给事物命名来进行沟通，也通过给事物命名来思考。这对于我们使用语言是至关重要的。这对我们来说并不难。我们每天都在做这件事。

在我们要创建的UML模型中，以“命名”的方式表达，表示要编程的模块，如下所示。

我们所谈论和思考的事物彼此之间是相互关联的。考虑到这一点也属于面向对象的概念之一。在语言中，我们发现事物之间的关系体现为动词（主语-谓语-宾语）。LED与控制器相连。这也可以在UML中表示出来。

在面向对象编程中，我们考虑的一种非常重要的关系是，某物可以属于特定的组。我们将在这门课程中编程的控制器属于STM32系列。通过UML，我们学会了抽象地建模这种情况。

概括总结：

面向对象意味着给事物赋予有意义的名称（抽象，类）
事物彼此相互连接
- 事物彼此了解/使用（关联，依赖）
- 事物由其他事物组成（聚合，构图）
事物属于组（抽象，泛化，专业化，实现，重用）

面向对象基本概念的详细学习

根据描述，UML已经发展成为一种成熟的表达技术，特别适用于建模面向对象的软件。通过国际标准ISO 19505，UML在全球范围内具有约束力。对于使用UML，起初只需要一些简单的图表和一小组符号就足够了。

正如描述所示，UML包含一系列不同类型的图表，严格按照其是否可视化结构或行为进行排序。在UML中，没有一种表达技术同时涵盖结构和行为。

用例图(应用案例图)从用户的角度展示了正在开发的系统。UML和SysML提供了这种表达形式，以澄清谁用什么做什么。在开发过程中，它特别适用于可视化主要需求或用于系统主要功能的文档化。

谁是用户，用一个小人图标表示。如果系统的用户是另一个外部系统，则将其表示为立方体。
用什么是指所描述的系统本身。
为了说明什么属于系统，什么在系统外部，应该将系统边界表示为框架。
应用案例是指系统为用户或其他系统提供的服务。用户与他使用的应用案例有关，这些关系代表用户与系统的交互，因此应该以不确定的方向绘制。
用例可以互相调用，这些调用以虚线显示。

在这门课程中，我们使用应用案例图来可视化对待解决方案的主要要求。随着学习的进行，图示会逐步变得更加复杂。

用例图的详细内容

活动图与长期已知且广泛使用的流程图有很大的相似之处。这些甚至可以在某些用户手册中找到。它们是自解释的，易于理解的。右侧显示的活动图是对用例“用户使用智能手机拨打电话”进行细化的。在这个用例中，用例代表了能够拨打电话的智能手机的主要要求。活动图更详细地描述了这个过程。

用例=主要需求
活动图=功能需求

通过这个活动图，可以自动生成系统的文本测试说明，即所谓的测试用例或测试场景。

场景：用户拨打电话-路径1

1. / Start
2. user / switches on the smartphone
3. smartphone / booting
4. smartphone / asks for the PIN
5. user / enters the PIN
6. / PIN
7. smartphone / checks the pin
8. smartphone [PIN is wrong] / shows an error message
9. user / enters the PIN
10. / PIN
11. smartphone / checks the pin
12. smartphone [PIN OK] / shows the start screen
13. user / click the phone icon
14. smartphone / shows the numeric keypad
15. user / dials the phone number
16. smartphone / establishes the connection
17. user / speaks to the called party
18. user / hangs up
19. smartphone / closes the connection
20. / End

显示的活动图由以下显示元素组成：

单个动作=带有圆角的矩形
流程开始=黑点
流程结束=圆圈中的黑点
决策=菱形有两个出口
分区（负责操作）=动作周围的边框
控制流=带有箭头的方向链接
数据元素/数据流=矩形

有关活动图的更多详细信息

类图是最重要的UML图表。这些是软件的实际设计图。到目前为止，应用案例图和活动图仅用于确保软件开发人员拥有足够的信息来构建和实现软件。我们不仅使用类图进行构建，还用于实现。通过类图不仅可以表示软件的结构，还可以从该图生成源代码。

类图中最重要的元素是类。我们可以将类理解为系统组件。嵌入式系统中的所有组件都是潜在的类。这些可以是传感器、执行器、按钮、LED、显示器、其他控制器，甚至是内部组件如定时器。每个组件都由类（矩形）在构造图中表示。每个组件可以具有属性（特征）和行为（操作）。这些在UML类图中作为类符号内的列表显示。类本质上是类型。程序员必须创建类的实例（类比变量）才能使用它们。由于在嵌入式系统中，所使用的硬件通常只需要作为一个实例，所以在类设计的视角中，类和对象、类型和实例之间的区别并不重要。这只有在需要编写C++代码来实现所需逻辑时才变得重要。

模块=类+
- 属性=属性 Attribute
- 行为=操作 Operationen
对象=类的实例

在面向对象设计的基本概念中，我们已经了解到，系统组件之间的关系对于嵌入式系统软件的设计是非常重要的。听起来复杂的是，实际上比想象的简单。在开始时，我们可以将类之间的不同UML关系类型的决定限制为仅两种。将这个决定转化为简单的语言，开发人员在模拟两个类之间的关系时只需问自己：

A类是B类还是
A类有B类？

示例1:

控制器是STM32还是
控制器有STM32？

答案很清楚是“是“

示例2:

控制器是LED还是
控制器有LED？

在这种情况下，答案显然倾向于“有”

这样一来，我们就可以在开始时将所需的关系类型限制为以下类型：

概化/实现= 是实线或虚线带空头的箭头
聚合= “有” =实线带简单箭头

以下简单的类设计显示了所描述内容的应用：

翻译成简单的语言后，可以在该类模型中阅读以下内容：

模块SMT32，控制器，按钮和LED。
控制器**是**STM32。
控制器**有**一个按钮。
控制器**有**一个LED。
启动控制器 (start)。
运行控制器(run)。
控制器可以每10毫秒执行一次操作(onTimer10ms)。
按下该按钮 (isPressed)。
打开LED (on)。
关闭LED (off)。
切换LED (toggle)。

按下按钮，代码生成器为C ++中的LED类提供以下类声明代码：

class LED
{
   public: LED();
   public: ~LED();
   public: void on();
   public: void off();
   public: void toggle();  
};

有关类和类图的更多详细信息

序列图与活动图一样展示了系统中的运行方式。除了展示方式之外，最重要的区别是序列图中已经模拟了具体的消息。消息实质上是操作的调用。这意味着序列图更加具体和接近实现。活动图可以更大程度上抽象出C++或其他面向对象编程语言中的具体实现。序列图本质上更接近编码。以下示例展示了C++源代码和UML序列图之间的直接转换，这是通过生成器自动生成的。

Controller::onEvent100ms()
{
  if (led.getState())
  {
	led.off();
  }
  else
  {
	if (button.isPressed())
	{
		led.on();
	}
  }
}

在本课程中，我们使用序列图来记录选定的代码片段。这些图由生成器自动生成，并且可以在文档中代替源代码使用。

有关序列图的更多详细信息

在第一眼看上去，无论是源代码还是序列图，都无法直接展示程序的功能。这意味着人们首先需要在头脑中梳理出每100毫秒发生的事情。这个逻辑是事件驱动的，并且基于状态的开关。以下的描述展示了完全相同的算法，作为从状态ON到OFF的转换。

这个状态图更清晰地显示，受到每100毫秒事件驱动的影响，当按下按钮时LED在ON和OFF状态之间切换，因此LED在闪烁。在本课程中，我们也使用状态图进行编程。从状态图中可以生成源代码，就像从类图中一样。对于嵌入式系统的许多任务来说，是事件和状态导向的。因此，从清晰建模的状态机生成程序逻辑是值得的。

有关状态机的更多详细信息

在介绍中已经说明，现代系统需要跨学科理解。长期以来，没有一种跨学科的建模语言。每个领域都有高度发达和标准化的领域特定建模语言，但只有专业人士才能真正理解。领域特定建模语言不适合跨学科交流。SysML就是为填补这一空白而提供的一种解决方案。作为一种通用的系统建模语言，SysML从电气工程、机械、液压、气动、电子和软件的领域特定符号中抽象出来。尽管SysML的起源可以追溯到UML，并且许多元素与UML相对应，但SysML的重点不在于面向对象和软件，而是提供了对任何类型系统的建模能力。在跨学科系统关系的非标准化表达中，所谓的块图形成了一种常见的方法。这些图形根据个人意愿创建并理解或不理解。SysML介入到这里。块作为建模的基本元素，无论是机械的、电子的、液压的、气动的还是软件的块，都是标准化的，就像这些块之间的关系的表示一样。系统组件 - 块 - 类。谁能建立起这种联系，就已经非常接近SysML的意图。在UML和SysML的概念上的重叠在SysML和UML的相似结构中清楚地显示出来。将SysML的分类与UML的分类进行比较。