はじめに

自由は不自由や。

by ジョージ富士川

参考はこちらです

適度な制約（不自由さ）が自由な創作の拠り所となるという考えが大事だよって解釈かなと思います。
開発においても自由過ぎず不自由過ぎない適度な塩梅でやりましょうというのがモダンな考え方なんだと思います。ソシャゲ開発などではゲーム中毒者たちを飽きさせないために超高速回転でアジャイルしているらしいですし。

☓ やらないこと

☓　トップダウン型の開発
☓　複雑な規則は取り入れない
☓　難しいこと

##設計設計しない
プロセス中心設計、データ中心設計、構造化設計(トップダウン)、オブジェクト指向設計、多層アーキテクチャ

設計書に縛られない

個人開発においては設計のエッセンスは限りなく少なくする

依存地獄から逃れる

ルール通りに開発することは精神面で楽なことも多いと思う
が、ルールを課すことはそのルールに依存するということでもあるので
依存をできる限り減らす

◎ やること

◎　必要に応じて機能を追加(JIT)
◎　デプロイは自動化
◎　楽なこと

設計っぽいことをやる

全体の流れ

工程

要求分析　→　分析　→　アーキテクチャ設計　→　詳細設計　→　実装　→　テスト

成果物

ユースケーズモデル　→　イベントフロー　→　画面遷移図　→　概念モデル　→　分析モデル　→　アーキテクチャ設計書　→　設計モデル　→　ソースコード　テスト仕様書、テストコード

UML

ユースケース図　→　アクティビティ図　→　クラス図、オブジェクト図、コミュニケーション図　→　パッケージ図、クラス図、シーケンス図　→　クラス図、シーケンス図

まとめ

工程	主な成果物	UMLモデル図
要求分析	ユースケースモデルイベントフロー画面遷移図	ユースケース図アクティビティ図なし
分析	概念モデル分析モデル	クラス図、オブジェクト図コミュニケーション図
アーキテクチャ設計	アーキテクチャ設計書	パーッケージ図、クラス図シーケンス図
詳細設計	設計モデル	クラス図、シーケンス図
実装	ソースコード	なし
テスト	テスト仕様書、テストコード	なし

テーブル作成に用いたWEBツール
https://www.tablesgenerator.com/markdown_tables

補足①

上記は順不同
好きな（やりやすい）順にやる
データ揃っているならデータ設計(モデリング・詳細設計)から始めるのも全然あり

ミニマムなルール

箇条書き
文字数制限
用語集をつくる

少し詳細な流れ

アイディアを図にする
UIをスケッチする
文字やレイアウトなど
画面遷移図 (この段階で作らなくても良い)
実現したいこと（機能）を書き出す
列挙する
綺麗に整理する必要なし
must do , should do , could do
機能を実装する方法を考える
機能に優先順位をつける
本当に必要な機能かどうか
UMLっぽいものを書く (モデリング)
原則は守る
但し複雑な規則は取り入れない
ユースケース図 → オブジェクト図 → クラス図 → シーケンス図
ユースケース図
- システムで実現することを明確にする
- 検討対象のシステムがアクターに対して提供する機能・振る舞いのこと
- アクターとユースケースの候補は「誰が」と「名をするか」の観点で見つける
オブジェクト図
オブジェクトの持つ属性値の情報やオブジェクト同士のつながりを明記することで、システムのスナップショットを表現する
オブジェクト図は、クラス候補の洗い出しや、クラス間の関連や多重度など、クラス図を作成する際のヒントを得るために必要に応じて作成する
クラス図
システムの静的な構成を表現する
オブジェクトの情報を抽象的に定義したクラスとクラス間の関連を表現する
クラスの候補は、ユースケース図やオブジェクト図などから抽出する
クラスの属性や操作、クラス図の関連は、シーケンス図やアクティビティ図などから抽出する
それぞれのUMLを行ったり来たりしながら徐々に完成に近づける
シーケンス図
システムの振る舞いを時系列で表現する相互作用図
図の詳細度やクラス図との整合性に注意する
アーキテクチャを選択する
ちょうど良いフレームワークがあれば使う
自作するならドメインモデルっぽい構成など
コーディング
見直しは適当でOK
速攻デプロイしてしまう
デプロイ
自動デプロイ
上記を繰り返す
追加・変更を繰り返す(JIT)