プログラミング

【UML入門】ソフトウェア設計図を描く前に知っておきたいUMLの基礎知識

UML入門

こんにちは。

現役エンジニアのはやぶさ@Cpp_Learningです。

より正確にはソフトウェアの仕様検討から設計・実装まで行う現役エンジニアです。

前回『ソフトウェア開発入門チュートリアル』の記事を書きました。

ソフトウェア開発入門
【ソフトウェア開発入門チュートリアル】OpenCVとPythonで『物体追跡カメラ』を作るソフトウェア開発入門のチュートリアル記事を書きました。本記事では、OpenCVとPythonを使った『物体追跡カメラ』の開発を題材に、開発プロセス・設計・実装(コーディング)などのソフトウェア開発に関する知識を一通り学べる内容になっています。...

この記事でUMLを使って描いた状態遷移図(ソフトウェア設計図)について説明しています!

本記事では、”UML”を使ってソフトウェア設計図を描きたい!という人のために…

『ソフトウェア設計図を描く前に知っておきたいUMLの基礎知識』を説明したいと思います。

知りたガール
知りたガール
UML?何それ美味しいの?

という”知りたガール”さんでも分かるように、”UML”について丁寧に説明したいと思います。

プログラミングは楽しいけど、本記事をきっかけにソフトウェア設計(UML)にも興味を持ってほしなぁ(*・ω・)ノ♪

UMLとは

UML(Unified Modeling Language)とは、日本語だと“統一モデリング言語”と呼ばれており、ソフトウェア設計時に描く”モデル図”の記法を統一するために定められた”言語”のことです。

UML_モデル図

↑の図はUML(統一モデリング言語)を使って描いた”モデル図”です。

知りたガール
知りたガール
え?”図”なのに”言語”なの?

というのは当然の疑問だと思いますが、まぁそこは頭を柔らかくして…

はやぶさ
はやぶさ
ソフトウェアを”コード以外で表現”するメッセージツール

くらいの感覚で良いと思いますよ。

UMLの役割❶ -仕様書-

“知りたガール”さんの疑問は続く…

知りたガール
知りたガール
ソフトウェアを”コード以外で表現”する意味あるの?

例えば、何らかの理由で”言葉の通じない国”に来たとします。

はやぶさ
はやぶさ
「お腹が空いた」というのを相手に伝えるには、どうしますか?
知りたガール
知りたガール
えーと。お腹を抑えて…こんなポーズをとる
Body_Language

どういうポーズが正解かはさておき、多くの人は”言語が通じない”なら、Body Languageで相手に伝えようとすると思います。

ーーーーーーーーー

ソフトウェアの話しに戻します。

ソフトウェアはプログラミング言語で書かれています。

プログラミング言語が読めない人に、どんなソフトウェアを開発したか説明しなければいけないとき、どうしますか?

知りたガール
知りたガール
えーと。デモを見せる?

正解!完成品であれば、デモを見せるのが簡単です。

じゃあ開発前なら?

知りたガール
知りたガール
えーと。絵を描いて…

正解!プログラミング言語が読めないなら、絵などを使って伝えるしかないですよね?

でも、説明する人によって描く絵が変わると混乱しそうですよね?

なので、UML(統一モデリング言語)が必要なのです。

そして、ソフトウェアについてUMLで描かれた図は、そのまま仕様書として使うことができます。

UMLはプログラミング言語が読めない人に、ソフトウェアの仕様を説明するときに使えます。

UMLの役割❷ -ソフトウェア設計図-

上記のプログラミング言語が読めない人=非エンジニア…とは限りません。

例えば…

エンジニアA
エンジニアA
PythonはできるけどC言語ができない
エンジニアB
エンジニアB
C言語はできるけどPythonができない

という二人のエンジニアがいたとします。

プロトタイプ(試作品)はPythonで書いて、製品への実装はC言語で書きたい」という現場があったとします。

はやぶさ
はやぶさ
PythonもC言語も書けるけど、二人同時に指示を出したい…

こんなときのにもUMLが使えます。

PythonもC言語もプログラミング言語なので、文法の違いはありますが同じアルゴリズム(処理)を書くことができます。

基本的にプロトタイプ製品の仕様は同じなので、違うプログラミング言語で同じ処理を書く必要があります。

1つのプログラミング言語のみを使って、書いてほしいアルゴリズム(処理)の指示を出すと、片方のエンジニアは理解できません!

しかし、UML(統一モデリング言語)を使い、アルゴリズムに関するアクティビティ図や状態遷移図などの設計図を描けば、以下のように2人同時に指示を出すことができます。

はやぶさ
はやぶさ
下の設計図の通りにソースコードを書いて下さい
ソフトウェア設計から実装まで

つまり、UMLは修得していないプログラミング言語の壁を取り除いてくれるのです。

また『プログラミング言語の壁を取り除く』ということは、『UMLで描かれた設計図に対し、修得している言語やレベルにあまり依存せず意見をいえる!』ということです。

そのため、UMLで設計図を描けば、多くのエンジニアから意見を頂くこともできます。

UMLを使うことで、修得しているプログラミング言語にあまり依存せずに指示を出せたり、設計図に対する意見をいうことができます。

UMLによる仕様書と設計図の違い

“知りたガール”さんの疑問は続く…

知りたガール
知りたガール
UMLが仕様書・設計図の両方に使えるのは分かったけど、読み手が異なるよね?

“知りたガール”さん鋭いです!

UMLで書かれた仕様書と設計図の違いは以下の通りです。

【UMLのドキュメント】

  • 仕様書:だれが見ても分かるように記述
  • 設計図:エンジニア(コードを書く人)が分かるように記述

UMLを使ってモデル図を描くのは同じですが、読み手の違いを意識して描き方を変える必要があります!

日本語で書かれた本でも、児童向けと大人向けで文章の書き方が異なりますよね?それと同じことです。

知りたガール
知りたガール
理屈は分かったけど、どうやって描き方を変えるの?

まぁ当然そういう疑問がでますよね…

その疑問に答えるには『UMLの粒度』について説明する必要があります。

UMLの粒度

スマホゲームを例にUMLで書かれた仕様書と設計図の違いを見てみます。

スマホゲーム 読み手 書くべき内容
仕様書(取り扱い説明書) ユーザー 操作方法
設計図 開発者 ソースコードの内容

仕様書(取り扱い説明書読み手は”ユーザー”なので、ソースコードの内容を説明する必要がなく「操作方法のみ」を説明すれば良いです

一方、設計図の読み手は”開発者”なので、操作方法はもちろん「どんなソースコードが書いているか?あるいはどんなソースコードを書くべきか?」まで説明する必要があります。

少しだけ、ややこしい話をすると、ソースコードのテスト(動作確認など)をするために、開発者はユーザーという立場にもなります。

仕様書と設計図の違い

UMLに限らず、人に読まれる資料は、読み手を意識して作成する必要があります。

【実践】粒度の違うモデル図を描く

読み手の違いを意識したところで、実際にモデル図を描いてみます。

下図はUMLを使って描いたアクティビティ図(振る舞い図)の仕様書バージョン設計図バージョンです。

仕様書と設計図

仕様書(取り扱い説明書)の方は「どんな操作をするのか?」・「どうやってゲーム(処理)が進むのか?」を示しています。

一方、設計図は「どんな変数・関数を使うのか?」を示しており、さらに”game_start”という関数について別の設計図があったりします。

先ほどお見せした表に”粒度”項目を追加したものが、以下の通りです。

スマホゲーム 読み手 書くべき内容 粒度
仕様書(取り扱い説明書) ユーザー 操作方法 大きい
設計図 開発者 ソースコードの内容 小さい

仕様書(取り扱い説明書)の方はソースコードの細かい説明が不要なため、”粒度”が大きく設計図の方はソフトウェアの構造や振る舞いを説明するため”粒度”が小さくなる傾向にあります。

知りたガール
知りたガール
うーん。どの程度の粒度で書くのが正解なんだろう?

という疑問も当然ですが、粒度の大小に優劣はありません!

UMLの良い例・悪い例は以下の通りです。

読み手を想って描いた粒度なら大正解!

読み手を意識せずバラバラの粒度で描くのはNG!

粒度が小さすぎても見にくいし、粒度が大きすぎても理解できない!粒度がバラバラだと読み手は大混乱です!

はやぶさ
はやぶさ
読み手の”知りたい情報量”を意識して粒度を決めましょう!

なぜUMLが難しいのか?

“知りたガール”さん少し引っかかる部分がある様子…

知りたガール
知りたガール
はやぶさ先生なら仕様書レベルでコード書けそう!

…先生?それは置いといて、また鋭いですね!その通りです。

実は、仕様書(取り扱い説明書)レベルでもUMLによるモデル図があれば、ソフトを作成できるエンジニアはいます。

むしろ、先ほどお見せした設計図のように、変数や関数まで指定されるとかえってコードを書きにくい場合もあります。

これも「読み手である開発者を考慮して粒度の大きさを~」と一言で片づけても良いのですが、少しだけ”UMLの闇”を説明しておきます。

UMLの闇❶ -UMLツールとソースコード自動生成-

変数や関数も指定したモデル図を描いておくと、ソースコードを自動生成してくれる”UMLツール”があります。

つまり、UMLツールを使えば『モデル図生成=ソースコード生成』を実現できます!

この場合、読み手には優しくない”粒度がとても小さい”設計図になる傾向にありますが、悪いことばかりではありません!

復習ですが、UMLは『プログラミング言語の壁を取り除いてくれます!』

複数のプログラミング言語を修得しなくても、UMLを使いこなして詳細なモデル図(設計図)描くことができれば、多様な言語のソースコードを自動生成できるのです。

ソフトウェア設計から実装まで

そうすれば、設計図を書けるエンジニアが一人いれば、複数の言語でコーディングする工数を節約できます。

まぁ個人的には、ソースコードの自動生成って上手くできない印象なので…

設計(モデル図作成)とコーディング両方できて、コーダーの気持ちを考慮して設計できるエンジニアがカッコイイと思うよ(ง •̀ω•́)ง✧

(最新のUMLツールは使ったことないけど自動生成機能は進化しているのかな?)

以上のような”ソースコード自動生成”などの考え方があるため、”粒度は小さいほど良い”と主張する人もいます。

UMLの闇❷ -仕様書=設計図-

スマホゲームを例に仕様書(取り扱い説明書)と設計図の違いを説明しましたが、世の中には「開発者向けの製品」というものがあり…

職業柄、私がよく使うのはSDK(Software Development Kit)というソフトウェア開発者用向けのキットです。

SDKの場合、読み手が開発者しかいないため『仕様書=設計図』というのがほとんどです。

つまり、仕様書用と設計図用で粒度を変えたモデル図を描くのではなく、”適当な粒度”でモデル図を描き『仕様書=設計図』として、ひとまとめにするのです。

この”適当な粒度”の塩梅が難しく、SDKドキュメントを”仕様書(取り扱い説明)”として読むと詳細過ぎるし、設計図として読むと物足りなかったりします。

そのため、正解が書いてあるはずの”SDKドキュメント”や”UMLの参考書”・”ソフトウェア設計の参考書”を読んで勉強したはずなのに…

知りたガール
知りたガール
うーん。どの程度の粒度で書くのが正解なんだろう?

という”知りたガール”さんの悩みは解消されないままだったりします…

UMLの闇をまとめると以下の通りです。

【UMLの闇】

  • ソースコードを自動生成できるくらい”粒度の小さい”モデル図が正義!という考え方
  • UMLによるモデル図は『仕様書or設計図』論争
  • 粒度の大きさの最適解が分からない問題

以上 UMLの闇を少し見せたところで、まとめに入りたいと思います。

まとめ

”知りたガール”さんスッキリしたような…腑に落ちないよな…表情をしている。

知りたガール
知りたガール
UMLの理解は深まったけど、モデル図の描き方は分からない…?

まぁ無理もないですね…

本記事の後半で、UMLの闇を少し見せました!UMLに対して様々な考え方があるため、結局のところUMLの描き方に正解はなかったりします

もちろんケースバイケースで、一般的には”この粒度で書くと良い”という例が参考書に載っていますが…

「その粒度以外で描くと不正解なのか?」というと、そういうわけでもありません。

繰り返しますが、

読み手を想って描いた粒度なら大正解!

というのが持論です。

UMLの知識がある人に自分の描いたモデル図(設計図)を読んでもらい、ちゃんと意図(メッセージ)が伝わるなら、それは良いモデル図(設計図)です。

逆に言えば、”粒度の小さい”詳細なモデル図(設計図)を描いたつもりでも、読み手に意図(メッセージ)が伝わらないなら、それは配慮の足りないモデル図(設計図)です。

また、これも繰り返しますが、

はやぶさ
はやぶさ
ソフトウェアを”コード以外で表現”するメッセージツール

UMLの使い方であまり熱くなり過ぎず…

『相手にメッセージを正確に届けるには、どんな文章が良いか?どんな図を使うと分かりやすいか?』

について熱くなってほしいぁ(*・ω・)ノ♪

本記事は、UMLを学びたい!あるいはUMLについて学んだのに悩みが尽きない!!という人たちを対象に書きました。

少しでも参考になると嬉しいなぁ

はやぶさ
はやぶさ
理系応援ブロガー”はやぶさ”@Cpp_Learningは頑張る理系応援を応援します!

(完)

おまけ -UML劇場 三部構成-

時間に余裕のある人は、以下の茶番も読んでみてね!

第一部:UMLを使わなくたって

ふふふ…ほほほ……ふぉーふぉー

くるる
くるる
話は聞かせてもらった!

くるるちゃんいつからそこに?と聞く前にフクロウの”くるる””@kururu_owl が喋りだした。

くるる
くるる
くるるは”UML徹底活用”の本でUMLを勉強したの!
くるる
くるる
それで本記事の冒頭で出てきた以下の記事を再読したの!
ソフトウェア開発入門
【ソフトウェア開発入門チュートリアル】OpenCVとPythonで『物体追跡カメラ』を作るソフトウェア開発入門のチュートリアル記事を書きました。本記事では、OpenCVとPythonを使った『物体追跡カメラ』の開発を題材に、開発プロセス・設計・実装(コーディング)などのソフトウェア開発に関する知識を一通り学べる内容になっています。...

あぁ冒頭からいたのね…喋りたくてうずうずしてたのかな?一気に喋りだしたよ!笑

くるる
くるる
本では要求定義や要求分析にユースケース図を使ってるのに…この記事じゃ全然出てこないじゃん!
はやぶさ
はやぶさ
ほう!それで…分かりにくかった?

!!!!びっくりして全身の羽毛が逆立つ! そんな”くるる”も可愛い

くるる
くるる
あの記事すごい分かりやすかった!

そう!相手に伝わることが一番大事!相手に伝わるなら話題がソフトウェア開発だったとしてもUMLを使わなくたって良いのです。

もちろん、要求定義や要求分析をUMLで表現することもできました。

しかし、文章や写真で説明する方が分かりやすいと考たので、UMLを使いませんでした。

(”スサー”とかUMLでごちゃごちゃ説明するより、写真と文字の方が分かりやすいからね!笑)

くるる
くるる
納得した!UMLの勉強したから、なんにでもモデル図を描こうとしてた!読み手への配慮が足りなかった!!

実にしっかりした2歳児だ!笑

第二部:UMLマスターはオブジェクト指向マスターか?

うずうず…”くるる”が羽毛を揺らしながら呟く

くるる
くるる
UMLマスターしたらオブジェクト指向もマスターできる?

キラキラした瞳で質問してくれたのに申し訳ない…答えは”NO”です!

UMLオブジェクト指向をセットで説明する本などがあるため、”くるる”も勘違いしたのかな?

例えば、日本語が喋れても俳句が上手く作れない人は多いと思います。

俳句が『季語を入れた五・七・五の十七音からなる詩』というルールを知っていても、読み手に想いを伝える詩は、上手く作れないですよね?

”UMLをマスターした”というのは、日本語および俳句のルールを理解したレベルです。

オブジェクト指向はソフトウェア設計手法の一つです。より正確にはソフトウェアの構造設計手法の一つです。

ソフトウェアの構造設計で、UMLのクラス図を描くのですが、UMLを読み書きできるだけでは、読み手に想いを伝えるクラス図(設計図)を描くのは難しいです。

読み手に想いを伝える”俳句のテクニック”を学ぶように、読み手に設計の意図を伝える”設計手法・設計思想”を学ぶ必要があります。

なので、”オブジェクト指向”をマスターしたいなら、UMLだけではなく、ソフトウェア設計手法・設計思想も勉強してほしいぁ(*・ω・)ノ♪

はやぶさ
はやぶさ
オブジェクト指向なら以下の本とかオススメだよ
くるる
くるる
その本も読んだ!

…え!?マジでビビった!”くるる”…恐ろしい子

くるる
くるる
でも納得できる部分とできない部分があって…

…素晴らしい!

ソフトウェアの構造設計は、設計者の”設計思想”が…もっと単純に言えば”好み”が設計図に色濃くでます!

「自分ならこうしたい!」とか「この構造はシンプルだけど野暮ったい」などを考えることが、ソフトウェア設計者への第一歩です!

”くるる”は順調にソフトウェア設計者へと成長しようとしている!

くるる
くるる
ふむふむ。設計手法は本とか記事で学べそうだけど、設計思想って学べるの?

これは難しい質問…。先ほど説明した通り『設計思想≒好み』な部分もあります。

私の場合は、大量のクラス図(構造図)を熟読⇒考察⇒真似る!を繰り返して、自分好みの設計スタイル(思想)を修得したけど…そういう現場にいないと難しいよね。。

くるる
くるる
くるるは はやぶさ先生と気が合うと思うんよ!

ほう…?また先生??

くるる
くるる
はやぶさ先生の設計思想とかオブジェクト指向の記事読みたい!!

書いて!書いて!と言いながら足元でピョンピョンしている”くるる”が今日も可愛い!

はやぶさ
はやぶさ
いや~思想は人それぞれだし、オブジェクト指向なら良質な本や記事があるからなぁ

じーーっと見つめてくる”くるる”キラキラした瞳が眩し過ぎて直視できない!

まぁ…このサイトに遊びに来てくれる勉強仲間が増えたら考えるね!

わーい!!すぐ増えるから、すぐ完成するね!

(ふう…そう簡単にTwitterのフォロワーもサイトへのアクセスも増えないよね?)

第三部:ソフトウェア設計を勉強するときのアドバイス

最後の最後にアドバイス!

ソフトウェア設計図(モデル図)は読み手のことを想い「どうやってメッセージを伝えるか?」を考える抜いて完成した情熱の塊です!

勉強する人(読み手)は、このソフトウェア設計図(モデル図)に「どんなメッセージが込められているのか?」を考えると同時に…

「自分ならこうしたいなぁ」というのを考え続けて下さい!それを繰り返し実施すれば、自分の設計スタイルを見つけられるようになると思います!

あとは、UMLとかソフトウェア設計について議論できる仲間がいると良いね!

お互いの設計思想・設計スタイルをぶつけ合うことで、はじめて理解できることもあるからね!

正解・不正解ではなく、相手がどう考えたのかを学び、”良いなぁ”と思ったら素直に認めて吸収しましょう!

この記事をネタに議論しても良いよ!

ファイト(*・ω・)ノ♪

(完)

LINEスタンプ配信中!

フクロウのLINEスタンプ

当サイトのマスコットキャラクター

「フクロウのくるる」が

LINEスタンプになりました!

勉強で疲れたあなたに癒しをお届け☆

お迎え待ってます(*・ω・)ノ♪

今すぐお迎えする

40個セットがたったの50コインとお得です