目次
- あいさつ
- 本記事のコンセプト
- UMLとは
- 実際に描いてみよう
- まとめ
あいさつ
本記事をご覧いただき、ありがとうございます。
石川 聖(ヒジリ)と申します。
先日のポートフォリオ作成に続き、5本目の投稿となります。宜しければご覧ください。
今回は、システム開発の特に重要なUMLについての解説と実践をしていきます。
上流工程に進んでいきたい方、設計技術を上げていきたい方は是非、最後まで読んでいただきたいです。
また、いいねやコメント、ストックをしていただけると幸いです。
コンセプト
システム開発に重要なUML
システムを作るとき、いきなりプログラムを書き始めるわけではありません。どんな人が使うのか、どんな機能が必要か、どんなデータが扱われるのかといったことを事前に整理する必要があります。そのときに役立つのが「UML（Unified Modeling Language）」という図の表記法です。
UMLは、ソフトウェア開発の現場で広く使われており、設計の段階でシステムの構造や動きをわかりやすく表現できます。プログラミングの前にシステム全体を把握することで、後からの修正や開発メンバーとの連携もスムーズになります。
ただし、UMLと聞くと「難しそう」「専門的すぎる」と感じる人も多いかもしれません。実際、すべての図をきっちり覚える必要はありません。まずはよく使われる基本的な図を、簡単な例で体験してみることが大切です。
とりあえず簡単なケースで書いてみて理解を深めよう
このシリーズでは、まず簡単な題材を使って、UMLがどんなものかを体感できることを目指します。難しい専門用語や完全な図の正しさよりも、「なんとなくこういう場面でこういう図を使うんだな」と感じてもらえることを大事にしています。
今回は、身近な「図書館の業務」をテーマに、実際にUMLで図を描いてみます。図を描くことで、「現実の業務をどうやってシステムに置き換えるのか」という流れも自然とつかめるはずです。
なお、今回はあくまで入門編です。UMLの図にはいろいろなルールや種類がありますが、すべてを一度に学ぼうとしなくて大丈夫です。今後はもう少し本格的な設計や図の使い方についても別の記事で紹介する予定ですので、まずは気軽に読み進めてみてください。
UMLとは
UML概要
UML（Unified Modeling Language）は、日本語で言うと「統一モデリング言語」と訳されます。つまり、システムの構造や動きを図で表すための“共通ルール”です。
コンピュータのシステムは、人の目には見えないものです。だからこそ、設計をする段階で「どういう仕組みなのか」を誰が見てもわかる形で表す必要があります。そのときに使われるのがUMLです。
UMLでは、線や四角、矢印などを使って、システムの構成や動きを表します。図の種類によって「どんな機能があるか」「どんなデータがあるか」「どんな流れで動くか」など、さまざまな面を表現できます。
UMLは国際的な標準でもあり、世界中の開発現場で使われています。特に、複数人で開発を行う場合や、他の人と設計を共有したいときにとても役立ちます。
モデルとは
UMLを使って描く図は、「モデル」と呼ばれます。モデルとは、現実の複雑なものごとを、ある一面に注目して簡単に表現したものです。
たとえば、地図は「現実の地形」という複雑な情報を、「場所と距離」という視点にしぼって簡単に表しています。これと同じように、UMLのモデルも「現実の業務やシステム」を、特定の視点でわかりやすく表したものです。
システム開発では、主に次の3つの視点からモデルを作ります。
-
機能の視点
そのシステムで「どんなことができるのか」という視点です。誰が何をするのか、を表します。
-
静的な視点
どんな情報（データ）や構成（部品）が存在しているか、を表す視点です。動きではなく“形”に注目します。
-
動的な視点
時間の流れに沿って「何がどう動くのか」という視点です。動作や処理の流れを表します。
この3つの視点をおさえておくと、UMLの図がどういう目的で使われているのかがつかみやすくなります。
UMLを書く意味
開発者とクライアントの共通言語になる
UMLの最大の目的は、「関係者同士で同じイメージを共有すること」です。たとえば、開発者とお客様（クライアント）が会話だけで仕様を決めようとすると、言葉のとらえ方がずれて誤解が生まれることがあります。
UMLを使えば、曖昧な言葉の代わりに、誰が見ても同じ図で意思疎通ができます。これは、建築の世界で、建築家が図面を描いて工事会社に伝えるのと同じようなイメージです。
上流から下流への橋渡し
UMLは、システムの設計からプログラミングへと進んでいく開発の流れの中で、一貫して使える手法です。上流（要件や仕様）から下流（実装）へと、考え方をつなげる役割もあります。
特に、オブジェクト指向プログラミング（OOP）では、クラスやオブジェクトの関係を事前に整理することが大切です。UMLはその整理に役立ち、実際のコードを書くときにも役立つ図となります。
実際に描いてみよう
アナログ業務の把握
【図書館業務の概要】
図書館の貸し出し・返却業務では、以下の登場人物と情報が登場します。
- 登場人物：
- 利用者（本を借りる人）
- 職員（貸し出し・返却処理を行う人）
- 扱う情報：
- 利用者帳簿
- 本の情報
【貸し出し業務のフロー（紙ベース）】
- 利用者が本を借りたいと申し出る
- 職員が利用者帳簿を確認し、該当利用者が登録されているかを確認する
- 問題なければ帳簿に貸出記録を手書きで記入する
- 本に貸し出し中であることを記録する（例：カードに日付記入）
【返却業務のフロー（紙ベース）】
- 利用者が本を返却しに来る
- 職員が利用者情報と帳簿を照合し、該当の貸出記録を探す
- 該当の記録を更新（返却済みと記録）し、本を棚に戻す
システム化の視点で見直す
次に、アナログ業務をどのようにデジタル化するかを考えます。
【システム化の目的と概要】
- 貸し出しや返却の情報をデジタルで管理し、効率化・正確化を図る
- 操作の主体は職員（利用者の代わりに操作）
【システムにおける業務フロー】
- 貸し出し：
- 利用者を検索または新規登録
- 本のIDを入力して貸し出し登録
- 貸出履歴が自動生成される
- 返却：
- 本のIDから該当の貸出記録を検索
- 返却処理を行い、ステータスを更新
- 必要に応じて履歴確認
【情報構造（エンティティと属性）】
- 利用者：ID, 名前, 電話番号
- 本：ID, タイトル, 著者, 大分類, 小分類
- 貸出履歴：貸出日, 返却期限, 返却日, (利用者ID, 本ID)
UMLで表現してみよう
ここからはUMLを使って、システムの要素を視覚的に表現していきます。
ユースケース図(機能的側面)
ユースケース図は、「誰が（アクター）」「何をするか（ユースケース）」を表した図です。
システムの使い方や機能の全体像を把握するために使います。
- アクター（利用者の役割）
- ユースケース（やること）
この2つの関係を線で結んで表現します。
【アクターの明確化】
- 貸し出し係（職員）が主なアクター
- 会員はシステムの直接の利用者ではないのでアクターではない
【ユースケースの抽出】
- 会員登録
- 本の貸し出し
- 本の返却
- (貸出状況の確認などあったら便利だが、省略)
クラス図(静的構造)
クラス図は、システムに出てくる「もの（クラス）」と「もの同士の関係」を表した図です。
システムの中にどんな情報があり、どうつながっているかを整理するために使います。
- クラス（情報のまとまり）
- クラス同士の関係（関連）
これらを箱と線で表します。
また、クラス図は「多重度」というものがあります。
これは、クラス同士の関係で「どれだけの数量がひもづくか」を表すものです。
例：1人の会員が5冊まで本を借りられる → 多重度1..5
先ほど述べたように、システムは以下のクラスを扱います。
- 会員
- 本
- 貸出
これぞれの多重度は以下のようになります。
- 会員と貸出
- 1人の会員は0または1件の貸出を持つことができる（0..1）
- 上記の「総貸出数が5冊以下でも、一旦、すべて返却しないと新たな貸し出しはしない」という仕様から
- 1人の会員は0または1件の貸出を持つことができる（0..1）
- 貸し出しと本
- 1件の貸出に対して1冊から最大5冊の本を持つ（1..5）
- 上記の「貸出上限が5冊」という仕様から
- 1件の貸出に対して1冊から最大5冊の本を持つ（1..5）
- 本と貸出
- 1冊の本は0または1件の貸出にひもづく（0..1）
アクティビティ図(動的挙動)
アクティビティ図は、「処理の流れ」を表す図です。
業務やシステムで何を順番に行うか、どこで分かれ道があるかを視覚的に整理するために使います。
活動（アクション）を順番に並べ、条件分岐やループも表現できます。
貸し出し処理の流れをアクティビティ図で表現してみます。
【貸し出しシナリオの流れ】
- 会員確認
- 貸し出しの有無の確認
- 貸し出し処理
- 本のID入力
- 貸し出し確定
まとめ
ここまでお付き合いしていただいた読者の皆様、誠にありがとうございます。
この記事では身近な例で、業務のシステム化をUMLで表現してみました。
使いこなせば強力な分析・表現のツールになります。一緒に学んでいきましょう。
このアカウントでは、週に一本のペースで投稿しております。
それでは皆様、また来週。