【Java発展学習13日目】UMLとアジャイル開発について

# 技術者間で利用される3つの言語
技術者間でコミュニケーションを行う場合、主に以下の3言語が利用される。

| 言語 | 内容 |
|:--|:--|
| 自然言語(natural language) | 一般に人々が利用する言語 |
| プログラミング言語(programming language) | プログラムのソースコードとなる言語 |
| モデリング言語(modeling language) | プログラム構造を端的に表現する言語(図) |

# UML(Unified Modeling Language)
[参考1: UML入門](https://www.itsenka.com/contents/development/uml/)
[参考2: UML](https://qiita.com/devopsCoordinator/items/7d460008177b318129ea)
**統一モデリング言語**とも呼ばれるUMLは、オブジェクト指向言語の設計図となるモデリング言語の「標準規格」となっており、以下の13種類に分類される。

| 分類 | 名称 | 描画内容 |
|:--|:--|:--|
| 構造図 | クラス図(class diagram) | クラス |
|   | オブジェクト図(object diagram) | インスタンス |
|   | パッケージ図(package diagram) | パッケージ |
|   | コンポーネント図(component diagram) | コンポーネント |
|   | コンポジット構造図(composite structure diagram) | システム(ソフトウェア) |
|   | 配置図(deployment diagram) | システム(ハードウェア) |
| 相互作用図<br>(振る舞い図) | シーケンス図(sequence diagram) | オブジェクト・処理(時間的) |
|   | コミュニケーション図(communication diagram) | オブジェクト・処理(体系的) |
|   | タイミング図(timing diagram) | ライフサイクル |
|   | 相互作用概要図(interaction overview diagram) | 相互作用図 |
| 振る舞い図 | アクティビティ図(activity diagram) | 処理 |
|   | ステートマシン図(state machine diagram) | オブジェクト |
|   | ユースケース図(use case diagram) | システム化対象領域 |

## クラス図
**クラス図**は、「クラス定義」や「クラス間の関連性」など、**クラス構造**を表す。

![ClassDiagram.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/55428eb2-9e36-c622-c84d-07b4f73bb5b3.png)

```text:Class.wsd
@startuml
    ' メンバのアクセス修飾子
    ' +: public
    ' #: protected
    ' ~: package private(デフォルトアクセス)
    ' -: private
    interface CreatureMove {
        void move()
    }
    class Creature {
        -Belongings belongings
        +void move()
    }
    class Hero {
        -Pokedex pokedex
        -Party party
        +void fight()
        +void shopping()
    }
    class Party {
        +Hero hero
        #Pokemon pokemon1
        #Pokemon pokemon2
        #Pokemon pokemon3
    }
    class Pokemon {
        -String name
        +void attack()
        +void defend()
    }
    class PokemonCenter {
        +void heal()
    }
    class PokeLot {
        +void draw()
    }

    ' CreatureはCreatureMoveを実現(realization)
    CreatureMove <|.. Creature
    ' Hero,PokemonはCreatureを汎化(generalization)
    ' -> Creature1体に対してHero, Pokemonは1体
    Creature "1" <|-- "1" Hero
    Creature "1" <|-- "1" Pokemon
    ' HeroはPartyのコンポジション(composition)
    ' Party1つに対してHeroは1人
    Party "1" *-- "1" Hero
    ' PokemonはPartyに集約(aggregation)
    ' Party1つに対してPokemonは1匹以上6匹以下
    Party "1" o-- "1..6" Pokemon
    ' PokemonはPokemonCenterに依存
    PokemonCenter <.. Pokemon
    ' PokemonCenterとPokeLotは関連(association)
    ' PokemonCenter1箇所に対してPokeLotは1箇所
    PokemonCenter "1" -- "1" PokeLot
@enduml
```

### クラス間相互関係
**クラス間相互関係**を表す用語は、以下の通り。

| 関係 | 内容 |
|:--|:--|
| 関連(association) | 結びつき |
| 集約(aggregation) | 構成 |
| コンポジション(composition) | 強い集約(双方が依存) |
| 依存(dependency) | 片方に依存 |
| 汎化(generalization) | is-A関係 |
| 実現(realization) | 実装 |

## シーケンス図
**シーケンス図**は、「オブジェクト間のメッセージのやり取り」を**時系列**に沿って表す。
また、時系列の中での**イベント状態**をライフライン上で表す。

![SequenceDiagram.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/80f9e75e-b568-0f52-2d80-69e8b0838299.png)

```text:Sequence.wsd
@startuml
    Hero -> Balbasaur : "summon"
    activate Balbasaur
    Opponent -> Charmander : "summon"
    activate Charmander
    Balbasaur -> Charmander : "Solar Beam"
    Balbasaur <-- Charmander : "Decreased HP by Solar Beam"
    Balbasaur <- Charmander : "Flamethrower"
    Balbasaur --> Charmander : "Decreased HP by Flamethrower"
    ...5 minutes later...
    Balbasaur <- Charmander : "Flamethrower"
    Balbasaur --> Charmander : "Decreased HP by Flamethrower"
    Balbasaur -> Hero  : <<sendLose>>
    Balbasaur <-- Hero : <<responseOK>>
    deactivate Balbasaur
    Charmander -> Opponent : <<sendWin>>
    Charmander <-- Opponent : <<responseOK>>
    deactivate Charmander
@enduml
```

## ユースケース図
**ユースケース図**は「要件定義」の工程で利用され、「システム化対象領域」を表す。

![UseCaseDiagram.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/673880/418cc2d6-d1f9-a0eb-9ad6-68e9068d0735.png)

```text:UseCase.wsd
@startuml
    actor User
    rectangle requirement as "requirement definition" {
        usecase save
        usecase load
        usecase quit
    }
    actor FileServer

    User -- save
    User -- load
    User -- quit

    FileServer -- save
    FileServer -- load
@enduml
```

***

# 開発プロセス
主な開発プロセスは、以下の3種類。

| 開発プロセス | 内容 |
|:--|:--|
| ウォーターフォール型(water-fall model) | 各工程を終えてから次の工程に進む手法 |
| スパイラル型(spiral model) | 各工程を繰り返して行い、最後にリリースを行う手法 |
| アジャイル型(agile model) | 各工程を短期間で繰り返して行い、何度もリリースを行う手法 |

また、**アジャイル開発**は**XP(eXtreme Programming)**と**スクラム(scrum)**に分類される。

## エクストリーム・プログラミング(XP)
[参考1: Extreme Programming(XP)](https://www.agilealliance.org/glossary/xp/#q=~(infinite~false~filters~(postType~(~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'xp))~searchTerm~'~sort~false~sortDirection~'asc~page~1))
[参考2: Extreme Programming](https://people.engr.ncsu.edu/efg/517/f09/common/lectures/notes/lec21.pdf)
XPで定義された、開発者に必要な「5つの価値観」と「19のプラクティス」は、以下の通り。

| 価値観 | 内容 |
|:--|:--|
| コミュニケーション(communication) | プロジェクトメンバー間での円滑なコミュニケーションを行う |
| 簡潔性(simplicity) | 無駄を省くことで保守性を高める |
| フィードバック(feedback) | 改善と実践(プラクティス)を繰り返す |
| 勇気(courage) | 進捗・不具合・仕様変更に対して柔軟に対応する |
| 尊重(respect) | プロジェクトメンバーを尊重したフィードバックを行う |

| 分類 | プラクティス | 内容 |
|:--|:--|:--|
| 共同(joint) | 反復(iterations) | フィードバックに対する改善の反復 |
|   | 共通語(common vocabulary) | 理解の共有 |
|   | オープンな作業空間(open workspace) | コミュニケーションの円滑な職場 |
|   | 振り返り(retrospectives) | 定期的なフィードバック |
| 開発(development) | テスト駆動開発(test-driven development) | 要件を満たすテスト主導の開発 |
|   | ペアプログラミング(pair programming) | ドライバー役とナビゲーター役のペア開発 |
|   | リファクタリング(refactoring) | ソースコードの改善 |
|   | ソースコードの共同所有(collective ownership) | メンバー全員がコードの責任者 |
|   | 継続的インテグレーション(CI; continuous integration) | ビルドとテスト(=統合)の短期的な反復 |
|   | YAGNI | シンプルな実装(You Aren't Going to Need It.) |
| 管理(management) | 責任の受け入れ(accepted responsibility) | メンバー主体でのチーム開発 |
|   | 支援(air cover) | 継続的なメンバーへの支援 |
|   | 四半期ごとの見直し(quarterly review) | 定期的な必要事項の精査 |
|   | ミラー(mirror) | 課題発見、メンバーへの提案・鼓舞 |
|   | 持続可能な進度(sustainable pace) | 適切な開発ペース |
| 顧客(customer) | 要件の精査(storytelling) | 反復可能な要件量 |
|   | リリース計画(release planning) | 機能の順序付け |
|   | 受け入れテスト(acceptance tests) | プログラム完成後の迅速な受け入れテスト |
|   | 小規模リリース(frequent releases) | プログラムの段階的改良 |

## スクラム(scrum)
スクラムで定義された、プロジェクトメンバーの「3つの役割」「3つのリスト」「4つのミーティング」は、以下の通り。

| 役割 | 内容 |
|:--|:--|
| プロダクトオーナー(PO; product owner) | 「製品としての成果」を求める、製品に関する最終責任者 |
| スクラムマスター(SM; scrum master) | 「チームの成長」を求める、開発チームの管理者 |
| 開発メンバー | デザイナーやテスターを含む、開発を行うメンバー |

| リスト | 所有者 | 内容 |
|:--|:--|:--|
| プロダクトバックログ(product backlog) | プロダクトオーナー | 要件・機能を優先度順に箇条書きしたリスト |
| スプリントバックログ(sprint backlog) | 開発メンバー | 要件・機能ごとの進捗状況を記述した表 |
| 障害リスト(impediment list) | スクラムマスター | 開発中のあらゆる障害を懸念度順に箇条書きしたリスト |

| ミーティング | スプリント内での<br>実施タイミング | 内容 |
|:--|:--|:--|
| スプリント計画ミーティング | 最初の1回 | スプリントバックログの策定 |
| デイリースクラム | 毎日 | 進捗状況・問題点の共有 |
| スプリントレビュー | 最後の1回 | 顧客による評価・フィードバック |
| スプリントレトロスペクティブ | スプリントレビューの直後 | 今期スプリントの振り返り<br>次期スプリントでのチーム方針の策定 |

### デイリースクラムのプラクティス
デイリースクラムにおける「3つのプラクティス」は、以下の通り

<details><summary>1回につき15分以内</summary>
→ デイリースクラムの目的は「迅速な情報共有」</details>
<details><summary>割り込み・議論(質問)の禁止</summary>
→ デイリースクラムが長引く原因の排除</details>
<details><summary>全員への共有</summary>
→ 「自己組織化」されたチームへの昇華</details>

***

# 用語集

| 用語 | 内容 |
|:--|:--|
| バージョン管理システム(VCS; Version Control System) | ソースコードの変更を管理するシステム。<br>ソフトウェア構成管理(SCM; Software Configuration Management)とも呼ばれる。 |
| レポジトリ(repository) | ファイルの格納場所。 |
| フォーク(fork) | 他人のリモートリポジトリを自分のリモートリポジトリとして`clone`すること。 |
| プルリクエスト(pull request) | フォーク先ライブラリの変更点をフォーク元ライブラリに`pull`するよう依頼すること。 |
| 非機能要件(non-functional requirement) | ユースケース図では表現できない、性能・耐障害性・セキュリティなどの要件。 |
| マイクロサービスアーキテクチャ(micro service architecture) | 小規模システムを連携させて稼働させるサービス構造。 |
| WBS(Work Breakdown Structure) | プロジェクト計画と進捗状況を記述する資料。 |
| 懸案権利表 | 計画外の状況・課題をリストアップした資料。 |
| アジャイルソフトウェア開発手法(agile software development method) | 「アジャイル」をベースとした開発手法。 |
| イテレーション(iteration) | アジャイル開発における1回の工程反復期間。<br>「スプリント(sprint)」とも呼ばれる。 |
| スプリント(sprint) | 一般的に「2~4週間程度」の開発周期。 |
| 自己組織化(self-organization) | メンバー全員を「リーダー」として主体的に行動すること。 |
| ビルドパイプライン(build pipeline) | 「コンパイル→テスト→カバレッジ計測→Javadoc生成→アーカイブ処理」の一連の作業。 |
| 継続的デリバリー(CD; Continuous Delivery) | 高頻度かつ継続的にリリースすること。 |
| 継続的デプロイメント(CD; Continuous Deployment) | 自動的・継続的・高頻度でデプロイを行うこと。 |
| ビルドエージェント(build agent) | レポジトリに変更があった際に自動でビルドパイプラインの実行(CI)を行う開発支援ツール。 |
| CI/CD | 「継続的インテグレーション(CI)」と「継続的デプロイメント(CD)」を併せて実施すること。 |