102. github 上の開発ツール群の更新作業を確定する

前回の記事

はじめに

開発用PC の修理が終わったので、本格始動です。
今回から数回に渡り、2年前に開発・公開した、概念モデリングを使った変換による実装という開発プロセスを実現するためのツール群を更新していきます。今回はまず、github から公開している開発ツール群の棚卸をします。

公開ツール群

Knowledge & Experience の github は、

kae-made - Overview

です。概念モデリング ＆ 変換による実装 ＋ Digital Twins & IoT に関連するリポジトリ―を列挙すると、

• domainmodel-code-generator-csharp

  • ☆ 概念モデルを C# コードに変換するジェネレータ

• bridgepoint-extended-external-entities

  • ★ C# コード変換用の External Entity 定義 － BridgePoint で使用

• tutorial-generated-library-from-conceptual-model-with-azure-services

  • ★ 概念モデルを Microsoft Azure 上で動作する C# コードや設定ファイルを生成するチュートリアル

• domain-model-csharp-azure-digital-twins-adaptor

  • ☆ 概念モデルから変換した C#コードで Microsoft の Azure Digital Twins を概念インスタンスリポジトリとして使う場合に必要な C# コードライブラリ

• -domain-model-csharp-azure-digital-twins-iot-hub-framework

  • ☆ 概念モデルから変換した C# コードでを Microsoft の Azure Digital Twins と Azure IoT Hub を使う場合に必要な C# フレームワークライブラリ

• charp-code-generation-framework

  • ☆ 何らかのアーティファクトから C# コードを生成するツールに必要なフレームワークライブラリ

• state-machine-framework

  • ☆ 概念モデルを C# コードに変換するときに前提とする状態モデル用フレームワークライブラリ

    • IoT Device 側のライブラリ

    • Cloud（Azure Functions、Azure Digital Twins or SQL Server）側のライブラリ

• xtuml-ooa-of-ooa-library

  • ☆ BridgePoint で作成した概念モデルの内容を C# コードジェネレータで参照するためのライブラリ

• generator-framework

  • ☆ charp-code-generation-framework の骨格（変換後の言語に非依存）の部分のライブラリ

• dtdl-schema-generator

  • ☆ BridgePoint で作成した概念情報モデルを Azure Digital Twins の DTDL で記述された Twin Model に変換するツール

• azure-iot-hub-device-app-framework

  • ☆ Azure IoT Hub に接続する IoT デバイス or IoT Edge 上のアプリケーションの骨格

• domain-model-csharp-adaptor-samples

  • ★ domain-model-adaptor-viewers のサンプル

• iot-peripheral-devices

  • Raspberry Pi 用の BME280 や MHZ19B（CO2センサー）向けライブラリ

• kae-utilities

  • ☆ ジェネレータが生成した C# コードで使われるログ機構などの一般的なユーティリティライブラリ

• artifacts-building-management-tutorial

  • ★ ”ビル管理”ドメインのチュートリアル

• patterns-for-conceptual-model

  • ★ 概念モデルのパターン群

• domain-model-adaptor-viewers

  • ☆ domainmodel-code-generator-csharp で生成された C# コードセットを WPF デスクトップアプリケーションとして、または、Web アプリケーションとしてテスト実行するための Viewer。ある意味、BridgePoint の Simulator よりも 機能豊富（ But OAL 記述のラインデバッグは NG）

• artifacts-laundromat-in-hotel-tutorial

  • ★ ”ホテルのコインランドリー”ドメインのチュートリアル

• artifacts-product-sales-tutorial

  • ★ ”商品販売”ドメインのチュートリアル

• bp-model-patterns

  • ★ BridgePoint におけるモデルパターンカタログ

と、結構多めのリポジトリが関係します。まずは、☆ を付けたリポジトリが更新の対象になります。

リポジトリで公開しているライブラリやアプリケーションは、大きく分けると、コード変換ツール系と変換・生成されたコードが使うフレームワークライブラリ系の二種類があります。
☆印を付けたリポジトリだけ抜き出して、この分類に分けると、

• 変換・生成ツール系

  • アプリケーション系

    • domainmodel-code-generator-csharp

    • dtdl-schema-generator

    • domain-model-adaptor-viewers

  • ライブラリ系

    • charp-code-generation-framework

    • xtuml-ooa-of-ooa-library

    • generator-framework

• 変換・生成されたコードが使うフレームワークライブラリ系

  • domain-model-csharp-azure-digital-twins-adaptor

  • -domain-model-csharp-azure-digital-twins-iot-hub-framework

  • state-machine-framework

  • azure-iot-hub-device-app-framework

• 両方で使われるライブラリ系

  • kae-utilities

こんな感じになります。変換・生成ツール系は、更に、実際に概念モデルから C# コードに変換・生成するアプリケーションとして動作するものと、そのアプリケーションが利用するライブラリ（NuGet パッケージ）に分類しています。ライブラリ系は、それぞれが独立して様々なアプリケーションで利用可能と思われる一般化を施して切り出した結果作られたものです。結果的に、アプリケーションやライブラリは、別のライブラリーを使って作られていることになっています。
そのため、公開しているアプリケーション、ライブラリの更新は、その依存関係を逆にたどって、使われている側から順に行うことになります。

ツールの依存関係

それぞれのツールは Visual Studio で開発しています。一つのリポジトリには複数のプロジェクトが保持されていて、そのプロジェクトがアプリケーション、ライブラリのどちらかということと、リポジトリの依存関係は、それぞれのリポジトリ内のプロジェクトファイル（拡張子が .csproj）を見ればわかります。前述の☆印を付けたリポジトリ内のプロジェクトファイルの中身を順に調べていきます。

まず、domainmodel-code-generator-csharp を例に

このリポジトリには、5つのプロジェクトファイルが存在します。それぞれ内容を見ていき、アプリケーション or ライブラリ、依存するライブラリを調べていきます。

CodeGenerator/ConsoleAppCsharpGenerator/ConsoleAppCsharpGenerator.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <AssemblyName>DomainModelCsharpConsoleGenerator</AssemblyName>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\Kae.XTUML.Tools.Generator.CodeOfDomainModel.Csharp\Kae.XTUML.Tools.Generator.CodeOfDomainModel.Csharp.csproj" />
  </ItemGroup>

</Project>