対象読者
- ソフトウェア開発者全般
ゴール
- ソフトウェアアーキテクチャの概要がわかる
- レイヤーモデルがどのようなものかわかる
- ソフトウェアアーキテクチャ設計の実例を知ることができる
背景
筆者は趣味でテキストエディタ開発をしています。
今、開発を初めて1年半程度で、基礎的な動作の設計と実装ができた段階です。
最初はスクラップアンドビルドにより、ボトムアップでソフトを作成しました。
そしてその後、品質の高い設計とするために、トップダウンで再設計を実施しました。
その際に、今作っているソフトをどのようなアーキテクチャで作って行くかについての設計を行いました。
よって、その体験を通じて、知ったこと、考えたことや実践したことを紹介したいと思います。
ソフトウェアアーキテクチャとは
ソフトウェアアーキテクチャ（Software Architecture）は、ソフトウェアコンポーネント、それらの外部特性、またそれらの相互関係から構成される。
また、この用語はシステムのソフトウェアアーキテクチャの文書化を意味することもある。
ソフトウェアアーキテクチャの文書は開発依頼主とのコミュニケーションを容易にするもので、
概要レベルの設計に関する早期の決定を促し、プロジェクト間でのコンポーネントとパターンの設計を再利用することを可能にする。
(https://ja.wikipedia.org/wiki/ソフトウェアアーキテクチャ)
今回のアーキテクチャ設計のスコープ
- テキストエディタ全体の設計を対象とする
- 一般的なユーザインタフェーズのテキストエディタを開発することを想定する
- 例えば、Vim や notepad など
- もっとも抽象的なレベルの設計を実施する
- 後からはそれより具体的なレベルしか出てこないようにするため
再利用するアーキテクチャモデルの選定
アーキテクチャ設計を実施するにあたり、まず、再利用するアーキテクチャモデルの選定を行いました。
ソフトウェアアーキテクチャには例えば以下のような代表的なモデルがあります。
- MVC モデル
- レイヤモデル
- 具体例 : OSI 参照モデル
- クライアントサーバモデル
- データフローモデル
今回、筆者は以下のポリシーによってアーキテクチャのモデル選択を行いました。
- テキストエディタの構造を表現するのに適している
- 筆者自身がそのモデルに知見がある
よって、そのポリシーに従い今回の設計は「レイヤモデル」を採用することとしました。
理由は以下です。
- テキストエディタの主な構成要素であるバッファ、ウィンドウなどは階層的に表現しやすい
- 筆者がレイヤーモデルに基づく通信プロトコルを適用したソフトウェア開発の経験がある
設計したアーキテクチャ
今回、設計したテキストエディタのアーキテクチャは下図のようになりました。
Input はユーザの操作またはファイルによる入力で、
Output はユーザへ表示される、またはファイルなどで返される出力を示します。
以下が各レイヤの説明です。
- User Interface Layer
- ユーザ入力を抽象的な単位で受け取るレイヤ
- ユーザの入力はかならずこのレイヤをじてこれより下の層へと通じる
- Buffer Layer
- 編集しているテキスト全体の情報を保持するレイヤ
- テキスト、テキスト編集位置、などを情報をして持つ
- Window Layer
- ユーザへ表示するウィンドウの情報を保持するレイヤ
- ユーザから見えるテキスト、カーソル位置などを情報として持つ
- File I/O Layer
- ファイルの入出力を行うレイヤ
- Debug I/F Layer
- デバッグ用のインターフェースを持つレイヤ
- テキストエディタ機能により占有されたターミナルのバッファに代わりファイルなどにデバッグ出力を行う
今後は、追加していく機能や、実装規模の拡大に合わせて、層を追加したり、分割したりなどの追加設計は必要になる見込みです。
アーキテクチャから実装レベルへの表現
さて、アーキテクチャの設計ができました。
では、最後にその設計をもとにソフトウェアの実装へはどのように表現できるかを検討します。
筆者は、以下のパターンを検討しました。
- クラス、パッケージなどをコンポーネント(レイヤ)ごとに分割し namespace として表現する
- ファイルをコンポーネント(レイヤ)ごとに分割することにより表現する
筆者は、今回はプログラム言語の都合などから、ファイル分割による表現を選択しました。
(その理由については今回の記事のスコープではないため割愛します)
ソフトウェアアーキテクチャ設計を行うことにより得られたもの
アーキテクチャの設計を実施することにより得られたものは、今回は以下のようなものがありました。
- 機能が分割単位(ファイル)ごとに整理されるため、可読性が向上する
- 各層のつながりやデータフローを意識した API 設計ができるため、設計の品質が向上する
- ↑のようなメリットにより、機能を追加するときも適切な層に適切な I/F を追加することにより実現できるようになる
まとめ
ソフトウェアアーキテクチャというと大規模なプロジェクトなどのもの、と思ってしまうようなところもあったりしますが、
今回のような小規模なソフトウェア開発でも効果があることがわかりました。
また、それは今回のような組織の規模が小さい(今回は1人)開発でも有効であることもわかりました。
この記事を読んでくださった方で、まだ自分のためのプロジェクトでソフトウェアアーキテクチャを設計したことがない方は、
一度設計にトライしてみてはいかがでしょうか。