astahによるUMLモデリング

2020/11/14

VSCodeでDraw.ioが使える記事のリンク

VSCodeでDraw.ioが使える記事のリンクをメモ。

【参考】
VSCodeでDraw.ioが使えるようになったらしい! - Qiita

draw.ioでAWSのインフラ構成図を書く - Qiita

PlantUMLでAWSのインフラ構成図を描くやり方: プログラマの思索

インフラ構成図やシステム構成図で使えるアイコン集のリンク: プログラマの思索

astahでAWSインフラ構成図が描ける方法がある: プログラマの思索

最近、インフラ構成図もエディタとかastahで描きたいと思って、色々探している。
VSCode+PlantUMLやastahでAWSとかオンプレのサーバー構成図を書けるのは試していた。

VSCodeでDraw.ioが使えるなら、Visioみたいな感覚で何でも書ける。
最近のVSCdeはすごいね。

以前、Redmineパッチ会で、モブプログラミングをVSCodeのLive Shareプラグインでリモートで実現できていたのに驚いた。
レビューイが打ち込んでいるフォーカスやデバッグの画面が全て画面共有できる。

モブプロにVisual Studio Live Shareを使う - Qiita

最近は在宅勤務が当たり前なので、新人教育がやりにくい意見があった。
しかし、リモートでプログラミングのペアプロができるならば、新人プログラマの育成教育でも使える。
ツールが業務をどんどん改善していく。

インフラ構成図もUMLの一種のように書けるならば、単にモデルを情報共有できるだけでなく、そこからモデリング技術の知見も生まれるかもしれない。
いろいろ試してみたい。

| | コメント (0)

2020/11/05

第73回 SEA関西プロセス分科会 「モデルベースシステムズエンジニアリングの活用」 の見所 #seakansai

2020/12/12土の夕方に、SEA関西プロセス分科会 「モデルベースシステムズエンジニアリングの活用」が開催されます。

私も関わっているastah関西コミュニティの高井さんをお招きして、SEA関西にて「モデルベースシステムズエンジニアリングの活用」の講演2本が実現しました。

特に、自動車業界などで組込みソフトウェア開発を担当している技術者やアーキテクトに対し、上流工程におけるモデリング技法並びにモデリングツールを活用した設計技法のお話は参考になると思います。
興味のある方はぜひご参加ください!

講演の見所を少しだけメモ。

【申し込み】
第73回 SEA関西プロセス分科会 「モデルベースシステムズエンジニアリングの活用」 | Peatix

(引用開始・一部入れ替え)
開催日時: 2020年12月12日(土)16:00~18:00

開催形式: オンライン(ZOOM)

講師: 高井 利憲 氏(株式会社チェンジビジョン)

講演1:モデルベースシステムズエンジニアリングにおける形式手法の効果的な活用
 最近のシステム開発では上流工程での検証の必要性が高まっています。
 本講演では、モデルに基づくシステムズエンジニアリングアプローチと形式手法を組み合わせて活用する方法について、自動車分野のシステム開発を例に、ツールによる支援可能性を中心に議論します。

講演2:モデルベースシステムズエンジニアリングにおけるシナリオ生成手法の効果的な活用
 最近のシステム開発においては、シナリオベースの検証や妥当性確認を求められることが多くなってきています。
 本講演では、自動運転車の安全規格の一つであるISO21448(SOTIF)や同じく自動車分野のセキュリティ規格であるISO21434(車両サイバーセキュリティ)を例に、システムズエンジニアリングにおける効果的な実施方法を紹介します。
 講演1と同じ例題モデルを用いることにより、モデルの再利用可能性についても議論します。

本講演1及び2は名古屋大学倉地亮先生とdSpace藤倉俊幸様との共同研究の結果に基づいています。

主催: ソフトウェア技術者協会(SEA)関西支部

プログラム:
 15:30 アクセス受付開始
 16:00 講演1「モデルベースシステムズエンジニアリングにおける形式手法の効果的な活用」
 16:30 質疑応答
 16:45 講演2「モデルベースシステムズエンジニアリングにおけるシナリオ生成手法の効果的な活用」
 17:15 質疑応答・フリーディスカッション
 18:00 閉会

 閉会後、オンラインでの懇親会を持ちたいと思います。
 お時間の許す方は、お好きな飲み物をご用意の上、お気軽にご参加ください。

定員:
 100名
 お申し込み順です.定員になり次第受け付けを締め切ります.

(引用終了)

実は、過去に高井さんの講演や資料を見聞きして、刺激を受けた部分がたくさんある。
一つは、モデリングツールを経由して、開発プロセスと成果物のトレーサビリティを保証する仕組みを作り出すお話は面白かった。

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

ソフトウェア開発に置いて、開発プロセスが重要な理由は、単に手順を標準化して、作業の効率化を図るだけではない。
作業と成果物の間でトレーサビリティを保証することで、プロダクト品質とプロセス品質の両方を保証することだ。
例えば、ソースにバグがあれば、過去の変更履歴からどこでバグが埋め込まれたのか、どんな変更理由や要件の変更があったのか、を探れる。
あるいは、たった一つの仕様変更がどれだけの範囲のソースに影響を及ぼすのか、ということも追跡できるはず。
つまり、作業と成果物のトレーサビリティは、ソフトウェア構成管理に直結する。
ソフトウェア開発では、ソフトウェアの構成管理こそが、開発プロセスの本質ではないか、と思う。
そういう仕組みの実現に、実はastahというモデリングツールが一役買っている、という話が興味深かった。

2つ目は、SysMLというモデリング言語が、組込みソフトウェア開発において、メーカーのプロダクトオーナー、ハードウェア技術者、ソフトウェア技術者、自然科学者の間で、共通のコミュニケーション言語になっている、という講演も面白かった。

第2回astah関西の感想 #astahkansai: プログラマの思索

特に、組込みソフトウェア開発では、ハードウェア技術者が設計したハード機器に対して合うようなソフトウェアを開発するために、ソフトウェア技術者はどうしても弱い立場になりやすい。
そして、ハードの仕様変更や要件の理解不足などで、どうしてもソフトウェアの品質を担保するのは難しい。
その真因には、ハード技術者とソフト技術者の間で、コミュニケーションが不足しているから、ということがあるだろう、と思う。
ハード技術者にも理解してもらうために、UMLではなく、ハードの構造も表現できるSysMLを使うことで、ハード技術者とソフト技術者がSySMLという共通言語で会話できるようになった。
さらに、製品を市場にフィットさせる責任を持つプロダクトオーナーや、ハードに電気・流体・機械などの自然科学の制約を与えるドメインまで、すべての話をSysMLで会話できる。

多様なドメインを持つ製品開発では、こういう人工的なモデリング言語があるからこそ、ソフトウェアも含むハードを開発できるという点が面白い。
つまり、モデリング言語が我々の思考そのものを規定し、効率化させる部分があるわけだ。

今回の講演1本目は、モデルに基づくシステムズエンジニアリングと形式手法を組み合わせて検証する時に、astahというモデリングツールを使った事例を紹介してくれる。
モデリングツールによる検証方法の実装がどれだけ実現性があるのか、興味がある。

講演2本目は、自動運転車の安全規格などについて、システムズエンジニアリングにおける効果的な実施方法の事例を紹介してくれる。
自動車業界は今、ガソリンエンジンから電気自動車に大きく変更しつつある時代なので、こういう機能安全規格をいかにモデリング技法で実現するか、は、色んな観点で興味を引くはず。

最近、「モデルに基づくシステムズエンジニアリング」も読んでとても面白かったので、感想はまた今度書く。


| | コメント (1)

2020/10/30

「オブジェクト指向でなぜつくるのか」は良い本だ



オブジェクト指向でなぜつくるのか」を読んで、良い本だと感じた。
ラフなメモ書き。

10年前に書かれた第2版の本なのに、オブジェクト指向をキーワードにして、これだけ幅広く記載しているのはすごいな、と思った。
本にある図を参照して、イメージ図を自分で書いてみた。

Photo_20201030220601

「オブジェクト指向」を開発者が混乱するのはなぜか?
犬や猫の鳴き声をポリモルフィズムで表すとか、その例自体が混乱させる。
現実世界を全てオブジェクトに置き換えられるわけではないのに。

理由は、元々はオブジェクト指向プログラミングから発生したのに、オブジェクト指向設計や再利用部品群やデザインパターン、UMLなどの派生した概念と混同しているから。
特に、オブジェクト指向設計は汎用の整理術なので、オブジェクト指向プログラミングとは全く異なる。

オブジェクト指向プログラミングで、メモリ領域の話と絡めて説明しているのは分かりやすい。
メモリにクラスやインスタンスがロードされる感覚がなければ、良いプログラムは書けないだろう。

一方、オブジェクト指向設計では、クラスは集合、インスタンスは要素として集合論に持ち込んだり、メッセージパッシングからクラスの責務・役割分担へ発展させたりして、本来のオブジェクト指向プログラミングから離れた方向に向いている。

面白かった点は、ビジネスソフトウェアと組込みソフトウェアでは、設計・分析の考え方が違う点だ。
ビジネスソフトウェア設計では、システム化される業務と人間の手作業の業務を明確に分ける。
システム化された領域のうち、データモデルのみが現実の出来事の世界を反映しているに過ぎない。
だから、業務分析でシステムの境界を明確にし、システム化する業務を詳細化することが非常に重要になってくる。

一方、組み込みソフトウェア設計では、機械装置が最初にありき、で、機械装置の機能を全自動化するためにソフトウェアで実現する。
もちろんオブジェクト指向設計もできるが、機能の状態遷移図の方が設計でも重要になってくる。
つまり、どういう状況で、どういう動作を行うのか、という要求分析の方が重要になってくる。

この違いが面白い。
組み込みソフトウェア開発は経験がなかったので、この辺りのフィーリングの違いは興味深く読んだ。

オブジェクト指向の影響は、オブジェクト指向のプログラムは再利用しやすい点より、フレームワークやコンポーネントなどの再利用ライブラリを作り出した。
そして、再利用する設計思想を抽出するコンセプトから、デザインパターンが生まれた。
デザインパターンも数多くの流派を生み出した。
再利用できるイディオムやノウハウ、プロセスという観点で、アナリシスパターン、アーキテクチャパターン、そして、組織パターンなどがある。
XPもプロセスパターンの一種である、と考えれば、オブジェクト指向の影響が見受けられる。

Scrumも、「More Effective Agile」で一番気に入った言葉「スクラムチームはソフトウェアのコンポーネントのように振る舞うので、ブラックボックスとして扱うべきだ」から考えると、オブジェクト指向の影響を受けているように思える。
スクラムチームは自律的なチームなので、プロジェクトマネージャはチームのインプットとアウトプットだけ評価すればよく、マイクロマネジメントする必要はなく、チームをブラックボックスとして扱うべき。
スクラムチームはコンポーネントのように疎結合で独立してるならば、複数のスクラムチームを疎結合で組み合わせることで、内部の無駄な影響なしで大規模なチームを構成しやすくなる。
つまり、コンウェイの法則「アーキテクチャは組織構造に従う」を、複数のスクラムチームで構成された大規模な組織は、は良い意味で実現している。

そんなことまで連想させてくれて面白い。
そして、改めて、アジャイル開発はオブジェクト指向の影響を色濃く受け継いでいることを再認識した。

| | コメント (0)

2020/10/21

astahでオブジェクト背景にグラデーションを設定する方法

いつの頃からか、astahでオブジェクト背景にグラデーションがつかなくなった。
astahでオブジェクト背景にグラデーションを設定する方法が下記にあるのでメモ。

既存の図にグラデーションを設定する方法 | astah in 5 min

システムプロパティ>ダイアグラムエディタ>グラデーション図要素>横
に設定し、[プロジェクトに関する設定を現在のプロジェクトに反映する]にチェックを入れる。

| | コメント (0)

2020/10/20

複雑なUMLの代わりにC4モデルが提案されている

知人から、複雑なUMLの代わりにC4モデルが提案されていると聞いたのでメモ。

【参考】
ソフトウェアアーキテクチャのためのC4モデル

The C4 model for visualising software architecture

C4モデルを見ると、Webサービス用のアーキテクチャを描くためのモデリング技法みたい。
コンテナという要素もあるので、インフラ基盤も意識しているように思える。

下記のデモGifが分かりやすい。

C4-PlantUML/vscode_c4plantuml_snippets.gif at master ・ RicardoNiepel/C4-PlantUML ・ GitHub

UMLモデリングは僕は好きだが、確かに記法が複雑になってきているので、初心者には分かりにくいかもしれない。

僕が最近UMLに物足りないと感じるのは、クラウドに特化したモデリング記法やモデリングツールがないことだ。
単にアプリ層だけでなく、インフラ基盤のアーキテクチャも描きたい。
今はWebシステムはAWSのようなクラウド上に構築するのが当たり前で、AWSのサービスを駆使して開発するのが当たり前なので、どういうアーキテクチャに設計すればいいのか、をモデルとして描きたいのだ。

こういう簡単なモデリング技法を使うことで、アプリ開発者がインフラ基盤担当者と会話できるようになるといいなと思う。

| | コメント (0)

2020/10/06

インフラ構成図やシステム構成図で使えるアイコン集のリンク

インフラ構成図やシステム構成図で使えるアイコン集のページをリンクしておく。

ネットワーク図・システム構成図作成に使えるアイコン集 - Qiita

IT・Networkインフラでのプレゼンで使えそうなアイコン集 | ITnews on the Web

社内ネットワーク図に使えるパワーポイント無料アイコン集 | ビズルート

使える!!構成図に使うアイコン集|インフラタイムズ | ITの実践的な学習ができるサイト

以前、インフラ構成図やシステム構成図はVisioで作っていた時があった。
他には、ジョブ構成フロー図などもVisioだった。
VisioはExcelよりも図が書きやすいのがメリットだった。
しかし、Visioは有償製品であり割と高いのがデメリットだった。

最近、astahでインフラ構成図やシステム構成図を描く方法を教えてもらった。

astahでAWSインフラ構成図が描ける方法がある: プログラマの思索

astahのクラス図で、クラスのステレオタイプにアイコンファイルを取り込むだけなのだが、割と便利。
きれいに描けるのがいいし、astahで全てのモデリング作業を統一できるのもいい。

plantUMLでも同様に、アイコンファイルを取り込めば作図できるが、やっぱりastahが好きなので、astahで試してみる。

PlantUMLでAWSのインフラ構成図を描くやり方: プログラマの思索

| | コメント (0)

2020/10/03

astahでモデルを整理するにはクラスやユースケースの配下にモデルを置く

知人と議論しながら、astahでモデルを整理する方法について、考えたことをメモ。

astahのようなモデリングツールでモデルを書いていると、1個のファイルに何十個ものダイアグラムをたくさん書いて残したくなる。
たとえば、案件で分析フェーズのモデルと、詳細フェーズのモデルは観点や粒度が違うので、それぞれのモデルを区別して管理したい。
さらに、分析モデルと実装モデルをリンクするなどして、関連付けもしたい。

あるいは、複数個の案件を並行で担当していたら、それぞれの案件のモデルを区別して管理し、場面ごとに書き分けたい。
あるいは、過去の案件のモデルを参考にして、別のモデルを描くこともやりたい時もある。

今までの僕は、astahのパッケージを使って、Windowsのエクスプローラみたいに、フォルダ構造でツリー化してモデルを分けていた。
だから、詳細フェーズのモデルはツリー構造が深くなり、探しにくくなったり、分析モデルとの関連付けがやりにくいデメリットを感じていた。

モデリングツールで、たくさんのモデルをどのように管理していくべきなのか、色々考えていた。

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

知人から教わったことは、astahのクラスの配下に、クラス図やシーケンス図、ステートマシン図を置けること。
同様に、アクター、ユースケース、インターフェイスの配下にも、各種ダイアグラムを置くことができる。
最も驚いたのは、クラスのメソッドの配下にシーケンス図やアクティビティ図を配置できたことだ。

この機能の意味は直感的に分かる。
たとえば、ステートマシン図は、1つのオブジェクトがどのような状態に移るのか、を表しているので、1つのクラスに関連付けられる。
よって、ステートマシン図は、クラスの配下に置くべきだし、その方が直感的に理解しやすい。

たとえば、1個のユースケースに対し、ユースケース記述で業務フローを書くだけでなく、アクティビティ図で描いた場合、ユースケースの配下にアクティビティ図を配置すべきだし、その方が直感的に理解しやすい。

同様に、シーケンス図はクラスの1メソッドの流れを書いたものだから、クラス>操作の配下に置くべきだ。

そういう考え方を徹底すると、下記のようなモデル操作ルールが出来上がるだろう。

(1)分析フェーズでは、ユースケース図を描いて、登場人物とその利用シーンを洗い出す。
 ユースケース1個に対し、業務フローをアクティビティ図で描いて、そのアクティビティ図はユースケースの配下に置く。

(2)分析フェーズでは、概念モデルのクラス図を描いて、必要なクラスを洗い出す。
 クラス1個に対し、オブジェクトの状態遷移はステートマシン図で描いて、そのステートマシン図はクラスの配下に置く。
 クラスのメソッド1個に対し、メソッドの詳細はシーケンス図で描いて、そのシーケンス図はクラスのメソッドの配下に置く。

これにより、ユースケース図>アクティビティ図、クラス図>ステートマシン図・シーケンス図、というモデルの構造が全て階層化できることになる。
この階層化は、各ダイアグラムがどのオブジェクト(ユースケース)の詳細を示しているのか、を明示しているので、一貫した意味でモデルを整理できていることになる。

できれば、astah上で、こういう階層構造とともに、クラス(ユースケース)とダイアグラムの間で相互リンクできれば、要件からモデルまでのトレーサビリティが実現されるので、モデルの意味がより理解しやすくなるはずだ。

モデリングツールの新機能が、モデラーの設計技術を支援するだけでなく、モデラーの思考を刺激して新たな発想を生み出す。
そういう刺激を求めて、モデリングツールのあるべき姿を色々考えてみる。

Astah_arrange_under_class

| | コメント (0)

astahでAWSインフラ構成図が描ける方法がある

astahでAWSインフラ構成図が描ける方法がある、と知人から教えてもらったのでメモ。

【参考】
astah* 上でAWSアーキテクチャダイアグラムを書いてみよう | astah in 5 min

PlantUMLでAWSのインフラ構成図を描くやり方: プログラマの思索

PlantUMLによってコードベースでAWSのアーキテクチャー図を作る方法 - Qiita

astahでAWSインフラ構成図を描く方法は、AWSアイコンをクラスのステレオタイプに設定して、クラス図をインフラ構成図でみなすこと。

astahでAWSインフラ構成図を描けるメリットは、astah上で、アプリ層のアーキテクチャだけでなく、インフラ基盤のアーキテクチャも描けるので、システムのハード・ソフト全てをastahのモデルで一括管理できること。
最近は、クラウド上の開発が多いので、AWSサービスと組み合わせたアプリ開発が多いから、AWSインフラ構成図が描けると、設計モデルが理解しやすくなる。
特に、マイクロサービスが流行している昨今、AWSインフラ構成図をモデルで綺麗な絵として描けるメリットは大きい。

ただし、astahのAWSアイコンを1個ずつ読み込んで設定する作業は手作業しかないので、複数個のAWSアイコンを逐一設定するのが煩わしい。
astahのモデルでAWSテンプレートが提供できると便利なのだが。

暫定方法としては、複数個のAWSアイコンを設定したastahファイルを1個作っておき、それをテンプレートとして別ファイルで保持しておく。
既存のastahファイルでモデリングしている時、astahのマージ機能を使って、AWSアイコンのテンプレートであるastahファイルをマージして取り込むことで、手作業を防ぐことはできる。
最初に、AWSアイコンのテンプレートであるastahファイルを作る作業の1回分だけは我慢すれば、後はマージするだけで使えるようになるので、便利。

plantUMLでAWSインフラ構成図が描けるようになったことと同じように、モデリングツール一つで、アプリもインフラもモデリングできるようにしておきたい。
やっぱり、僕はastahが好きなので、astahでアプリもインフラも描けるようにしておきたい。

僕も今後試してみたいと思う。


| | コメント (0)

plantumlでタイミング図が描けるらしい

plantumlでタイミング図が描けるらしい、と知人から教えてもらったのでメモ。

【参考】
plantumlのタイミング図の構文

僕は業務系なのでタイミング図に疎いけれど、ハードウェア屋さんや組込みソフトウェア屋さんには、タイミング図が欲しくなる機会が多いらしい。
しかし、タイミング図の書き方は、ハードウェア屋さんの中でも、エレキ屋さんや本当のハード屋さん、さらにソフトウェア屋さんでは、微妙に違うらしいので、実際に書くのは難しい時があるらしい。

UML2の仕様では、タイミング図は2つの書き方があると言うのは知っていた。
たぶんその理由は、上記のような理由があるのだろう。

タイミング図を書きたい機会はまだ分かっていないので、色々調べてみたいと思う。


| | コメント (0)

Excelで業務フローを作成するアドオンがあった

オージス総研のHPに、Excelで業務フローを作成するアドオンを無償提供していたのでリンクしておく。
知人から教えてもらった。

業務フロー作成ツール(Activity Diagram Drawing Tool) ダウンロード | オージス総研

操作手順書を読むと、Excelのアドオンとして提供されて、アクティビティ図が描けるみたい。
パレットには、客・外・主・他のようなアイコンもあるので、日本企業向けに適している感じ。

Excelで業務フローが書ける利点は、設計書はたいていExcel仕様書なので、そのままアクティビティ図を埋め込むことができるからだ。
たぶん、外部設計書や要件定義書をExcelで書いている場合、このアドオンは重宝するのではないか。

Excelで業務フローだけでなく、クラス図やシーケンス図、ステートマシン図も簡単に描けるアドオンがあったら、日本のSIの現場では割と重宝されるかもしれない。

ただし、業務フロー図などの保守は面倒になるだろうな。
最初から書き直した方が速いかもしれない。


| | コメント (0)

より以前の記事一覧