設計とは何か
設計とアーキテクチャ
hr.icon
システム設計の目的は、ユーザーが要求する機能を実現するための仕組みを生み出すこと
求められる機能を実現するためにシステムが必要
機能を実現できるようなシステムになるように設計する
設計の基本的な考え方は、大きく機能設計・アーキテクチャ・構造設計からなる
アーキテクチャとは、（基本）設計を通じて設計者によりつくり出される「機能要素と構成部品との対応関係（マッピング）」や「構成部品間のインターフェースのルール」に関する基本的な構想
https://scrapbox.io/files/6339b94a87ec71002024d541.png
まず機能一覧を挙げて、それらを実現する構造を設計するってことねonigiri.w2.icon
その実現する構造の「各構成部品と各機能のマッピング」「構成部品間の連携の仕方」をアーキテクチャと呼ぶのか、なるほど。
最初は、機能設計から始まるんやろな
要望・要求を聞き、そこから要件定義を行う
その要件をもとに機能一覧が見えてくるようになるんだろう
システムを設計すると言ったら、必ず「基本設計」「構造設計」について考えることになる
最初の設計行為は、「基本設計」という言葉で表現される工程であり、「基本設計」「構造設計」を行うことになる。
機能設計
システムで実現する機能を決めて、詳細まで分解して構造化し、リストアップする。
成果物としては、機能の階層構造図ができるイメージ
構造設計
システムを形作る構成要素を決め、リストアップされた機能をどの構成要素で実現させるかマッピングする。
また、構成要素間の接続・連携方法も決める
基本設計の工程は以下
1. 実現機能を解析し、機能間の関係などを明らかにする
2. リストアップした機能を実現するために必要となる構造要素・モジュールがどれだけ必要となるのかを設計
3. 生成された構成要素・モジュール群に関して、どのモジュールでどの機能を実現するのかマッピング
4. モジュール間のインターフェース、つまり、接続方法を決める
それぞれの構成要素で更に基本設計が必要になる場合もある。その時も構成要素が持つ機能リストアップと構成要素のマッピングを行う必要がある。
なるほどなぁ....onigiri.w2.icon
とにかく機能リストアップと構成要素をマッピングを意識しておこう
詳細設計に進めない構成要素は、更にそこで設計を行う感じなんやな
システム設計の具体的作業
https://scrapbox.io/files/6339bcc800a6b8001d9ec418.png
これはすごい！！！onigiri.w2.icon
何がすごいかって、めちゃくちゃ汎用的な表現がされてる。
データアーキテクチャなんかは、今流行りのDDDのドメイン分析を近しいものを感じる。
システム基盤アーキテクチャは、まんまインフラ設計のことだろう。
あと注目したいのが、プログラム（構成要素）間のIFを早めに決めようとしてるところonigiri.w2.icon
早くIFを決めて、独立して開発できるようにしようねって言ってる。
いつもの開発でも気をつけてることだが、改めて言われるとやっぱりかと思って感心した。
>データアーキテクチャ
機能要件からデータモデルを全体共通で作成し、データのやり取りを共通化（これを“通信場”と表現する識者もいる）する。このことで、プログラム間の調整が終了し、以後、プログラムが独立に設計・製造が可能となる。開発法として、データモデル設計を先行させるDOA（Data Oriented Architecture）法と機能分割を優先させるPOA（Process Oriented Architecture）法の二つがある。オブジェクト指向開発では、これに当たるのがクラス設計である。 俺はユースケースから進めたい派ではあるonigiri.w2.icon
まあ、状況によって変えろとは言われるやろけど。
そうか、データモデルが決まりさえすれば、共通の約束事が決まることで、構成要素別に独立して開発しやすくなりそう
設計の評価基準
hr.icon
所謂以下
機能的強度や情報的強度のモジュールで、スタンプ結合やデータ結合の接続方式をとる場合、インターフェースの変更がない限り、相互に独立性が確保される。
少し思ってるのは...onigiri.w2.icon
小さい構成要素の範囲内では、外部結合・共通結合も無しではないなと思う。
共通で利用したいグローバル変数などがあった方が、便利な時もある。影響範囲が小さい限りにおいては。
グローバル変数を避けてバケツリレーなどをしてしまうと、逆にプログラムの可読性が落ちると思っている。
なので、影響範囲の小さい限りでは、途中までグローバル変数を使うというのも無しではないはず。