設計力につながる基本のお話（設計４：構成図・クラス図で構想をまとめよう）
設計力を身につけるナレッジ＃４
本ナレッジはプロを目指す方向けにしっかりと理解して頂きたい内容をまとめたナレッジです。
現役で活躍しているプログラマーであって設計力の不足が問題になることがあります。
しっかりとした設計力とプログラミング力を持ち合わせていればとても強力な武器・アピールポイントとなります。
構成図（AWSインフラ）
初めから完璧を目指さず、目的・目標・予算・開発効率や扱うデータの種類に応じてどのような環境を用意すべきかを考案します。
開発段階では最小限の構成で進めて、最終的には色々な条件を踏まえた上でマルチリージョン・サーバースペック・台数など決めて資料化します。
下図はAWSの知識が必要ですが、AWSの一般的なサービスを把握されている方には伝わるのではと思います。
なお、一般向け公開用の無料の資料のため詳細は書き込んでいません。
より具体的な構成図（インフラ以外も含む）の作り方に関してはご契約を頂いた方へご要望に合わせて説明させて頂きます。
主要サーバー構成図
私が開発しているウェブサーバーのインフラ構成のイメージ図です。
ウェブサーバー等のインフラをAWSを用いて構築する際に利用する大まかなサービスとVPC構成図です。
負荷分散・冗長化構成図
私が開発しているウェブサーバーの負荷分散・冗長化のイメージ構成図です。
AWS管理者向け機能一覧
現在、利用しているAWSの管理機能・サービスの一覧図です。
クラス図（簡易版）
主要なプログラミング言語にはデータ本体を保持し、そのデータを使用した処理を１つのグループとしてまとめる仕組みがあります。
また、このグループを複数用意してグループ同士をつなげることでグループ自身が持つデータの受け渡しをしたり、あるグループから派生させた新グループを作って一部だけ異なる処理結果になるようにロジックを変化させたりするための仕組みがあります。
このようなデータと処理を関連付けしてグループ化したもの主要な言語ではクラス（クラスオブジェクト）として表記されます。
学校の１学年１クラスのクラスと置き換えて考えると想像しやすいと思います。
一クラスには複数の生徒がいてみんなそれぞれ個性があって得意・不得意なことがあるかと思います。
クラス（教室）内に紙と鉛筆がれば字や絵を描けますし２人以上で会話したり、ほうきや雑巾があれば掃除ができます。
このクラス一つ一つに役割を決めて、それぞれ出来ることに応じて親子関係（学年の上下関係）を表現し相関図にしたものがクラス図です。
複数メンバーでチームを組んで行う場合はUMLなどしっかりとした規格に沿った資料を用意した方が伝達ミスは減らせます。
こちらのナレッジでは、クラス図が大まかにどのようなものであるかをお伝えするのみとさせて頂きます。
下図は私の個人開発プロジェクトのクラス構成図の一部です。
RESTful APIとしてCRUDのリクエストを受け取ってJSON形式で返す処理を実装しております。
クラス名 oTLbL6AApiJson が実際にJSON形式の文字列を生成する処理を実装しています。
このクラスをoApiLogin/oApiLogoutが継承しており、ログイン・ログアウトのAPIを実行した際にJSON形式でデータがレスポンスデータとして返されます。
oApiLogin/oApiLogoutが継承元のクラスをoTLbL6AApiXMLに変更することで各APIはJSON形式ではなくXML形式でデータをレスポンスとして処理を返すようにロジックが変わります。
こちらのクラス図で大まかにどのクラスがどんな処理を担っていてクラス同士の親子関係がどのようになっているかが伝わりやすくなります。
頭の中で描いている処理を整理して同じような処理は１つのクラスにまとめることで使いやすいシステムが出来上がります。
ソースコードを思い付きで書かず、まとめることで効率が上がります。
メリットとして、
- 同じソースコードは作らないですむ
- 不要な処理を作らないで済む
- 関数の行数を減らしを読みやすく短くする
- ソースファイル１つを大きくしすぎない
- 処理がまとまっているので対象コードが見つけやすい
など、メリットがたくさんあります。
相談などでソースコードを見せる際に見る側も解読しやすいです。
より具体的なクラス図の作り方に関してはご契約を頂いた方へご要望に合わせて説明させて頂きます。
