art_of_architect_part_2

art_of_architect_part_2

Transcript

1. 第２章 ソフトウェア設計 第２章 ソフトウェア設計 第２章 ソフトウェア設計
2. 目次 2.1　ソフトウェア開発プロセス 2.2　ソフトウェア設計の抽象レベル ソフトウェアの設計に必要な考え方である4つの抽象レベルを知る 第２章 ソフトウェア設計 第２章 ソフトウェア設計
3. やらないこと 本書の内容の詳しい説明 やること なぜやるのかの深堀り 設計の重要性について 第２章 ソフトウェア設計 第２章 ソフトウェア設計
4. 2.1 ソフトウェア開発プロセス 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
5. 目的 アーキテクチャの設計はソフトウェアの設計アクティビティの一種です。 ここでは設計とは具体的に何を指すのか、ソフトウェア開発プロセスの中でどの ような位置付けなのかを確認したいと思います。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
6. 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
7. 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
8. プロジェクトの作業工程（フェーズ）ではなくアクティビティの流れを表してい ることに注意してください。 ウォーターフォール開発プロセスの場合はそのままフェーズとなりますが、アジ ャイル開発プロセスの場合は1週間〜1カ月程度のイテレーションの中で、ユース ケース単位にこれらのアクティビティを実施します。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
9. アジャイル開発プロセスの場合 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
10. それぞれのアクティビティ どのような作業を行うか どのような成果物を作るか 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
11. 要求分析 前半 対象業務領域を分析し、業務上の課題をソフトウェアによって解決する観点でモ デリングを行います。 後半 各ユースケースを実現するために必要となる機能（画面や帳票、外部システムと のインターフェース）を定めます。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
12. 要求分析(前半) 作業 1. 顧客の現行業務（As-Is）のヒアリングを行い、業務の流れや業務ルールを整理 （前半） 2. あるべき姿（To-Be）を描く（後半） 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
13. 要求分析(前半) 成果物 業務フロー図 ユースケースモデル ユースケース図 ユースケース記述 クラス図 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
14. 業務フロー図 引用：https://product.strap.app/magazine/post/knowhow_workflow 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
15. ユースケース図 引用：https://it-koala.com/usecasediagrams-1832 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
16. ユースケース記述 引用：https://it-koala.com/usecasediagrams-1832 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
17. クラス図 引用：https://product.strap.app/magazine/post/knowhow_class-diagram 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
18. 【再掲】要求分析（後半） 各ユースケースを実現するために必要となる機能（画面や帳票、外部システムと のインターフェース）を定めます。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
19. 【再掲】要求分析（後半） 各ユースケースを実現するために必要となる機能（画面や帳票、外部システムと のインターフェース）を定めます。 これらの成果物を作成する作業を外部設計と呼ぶこともありますが、ソフトウェ アの外界との境界面の仕様を定めて顧客やその他のステークホルダーと合意を取 る必要があることから、 本書では 設計（design）ではなく仕様化（specification） として捉えます。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
20. 設計 要求分析アクティビティで定められた要求仕様をプログラミング言語やフレーム ワーク、ライブラリを使って実装する方法について具体的に計画します。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
21. 設計 なぜ設計が必要なのか？ 仮に要求仕様が「コンソールからの入力を受け取って挨拶文を表示する」という 単純なものであれば、設計するまでもなくコードを書くことができますが、実用 的なソフトウェアは規模が大きく複雑なのでそうはいきません。大規模で複雑な ものは一本のプログラムでは実装できないため、複数の構成要素に分割する必要 があります。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
22. 設計 作業 構成要素への分割方法 各構成要素への責務の割り当て 構成要素同士の相互作用 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
23. 設計 成果物 コラボレーション図 設計モデル・詳細設計書（WF寄り） CRCカード（アジャイル寄り） TDDによる実装と同時に行う設計（アジャイル寄り） 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
24. コラボレーション図 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
25. CRCカード Class（クラス） Responsibility（責務） Collaborator（コラボレータ） 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
26. 実装・テスト 設計に基づいて実際に動作するソースコードを実装します。でき上がったソフト ウェアにより要件が満たされることをテストで検証します。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
27. 実装・テスト 作業 割愛 実装・テスト 成果物 ソースコード 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
28. V字モデルにおける工程の分け方や名称はまちまちであり、統一された標準モデル はない点に注意。 「単体テスト」がプログラム単位なのか、画面単位なのか、はたまた機能単位な のかは企業やプロジェクトによって異なる。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
29. 余談：JSTQBでの単体テスト コンポーネントテスト（ユニットテストとも呼ばれる）は、コンポーネントを単 独でテストすることに焦点を当てる。 …明確な基準はなく、あくまで焦点（=目的）から定義されるものとしている。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
30. 重要なのは、自分たちのプロジェクトで採用する開発プロセスに合わせて、適切 なテスト計画を立てることです。 また、ウォーターフォールかアジャイルかに関わらず、早い段階からテストを行 う シフトレフト のアプローチ（ 第5章 を参照）も有効です。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
31. 2.2 ソフトウェア設計の抽象レベル 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
32. ソフトウェアの設計にあたっては抽象レベルを意識する必要があります。本書で は、 図2.2.1 に示す四つの抽象レベルに分けます。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
33. ❝ソフトウェアの設計にあたっては抽象レベルを意識する必要が あります。❞ 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
34. なぜ？ 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
35. あるアーキテクトの本で、ソフトウェアの設計にあたっては抽象レベルを意識する必 要があります。という文章がありました。 なぜソフトウェアの設計にあたっては抽象レベルを意識する必要があるのか考えを聞 かせてください。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
36. 1. 複雑さの管理 2. 変更に対する柔軟性 3. 再利用性の向上 4. チーム開発での分業 5. コードの可読性とメンテナンス性の向上 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
37. 自分なりには… レベルを分けなかった場合（=すべてのコードが一箇所に存在する場合） どの機能がどこに書いてあるのか分からない どことどこが依存関係にあるのか分からない コンフリクト起こりまくり ただでさえ複雑なソフトウェアに更なる複雑性を追加することになり手に負えない。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
38. RailsであればMVCを守るように規約で固められているのであまり意識することはな い。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
39. 再掲 ソフトウェアの設計にあたっては抽象レベルを意識する必要があります。本書で は、 図2.2.1 に示す四つの抽象レベルに分けます。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
40. クラス設計 クラス設計はプログラムの最小単位となる構成要素の設計です（オブジェクト指 向プログラミング言語の普及度が高いことからここではクラス設計としました が、もし関数型プログラミング言語を使う場合は関数がそれに該当すると考えて ください） 。1クラスを1ファイルに記述することが多く、概ねファイル単位の粒度 となります。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
41. クラス設計の例 2.2.5の注文リポジトリコンポーネントを詳細化してクラス図に落とし込んだ例 クラス設計では、各コンポーネントをクラスに分割し、複数のクラスの協調によ ってコンポーネントの責務が実現されるように設計します。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
42. コンポーネント設計 クラス設計よりも高い抽象度で、コンポーネントをどのように構成し、それらを 協調させるかを決める設計です。コンポーネントという言葉はよく使われます が、その定義はまちまちで、文脈によって異なる意味で使われることもありま す。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
43. コンポーネント設計 この本でのコンポーネントの定義 コンポーネントとは、特定の振る舞いを提供する責務を持ち、明確なインターフ ェースにより定義されたソフトウェアの構成部品のこと。しばしば複数のクラス から成り立つ。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
44. コンポーネント設計 コンポーネントが明確なインターフェースを持つということは、置き換えが可能 であることを意味します つまり、テストでスタブによる置き換えが可能 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
45. コンポーネント設計の例 ロバストネス図の場合 たとえば「注文を登録する」ユースケースを実現するために必要なコンポーネン トの抽出と、それらの相互作用について設計します 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
46. モジュール設計 モジュールとはコンポーネントの集合体です。コンポーネントは特定の振る舞い を提供しますが、コンポーネント単体ではソフトウェアのユーザーにとって意味 のあるタスクを実行することはできません。ユースケースの実行に必要な機能を 提供するため、関連するコンポーネントを集めた構造がモジュールとなります。 ソースコードとしては、配下に多くのコンポーネントやクラスが存在するパッケ ージのツリー構造全体がモジュールに該当するイメージです 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
47. モジュール設計の例 マイクロサービスアーキテクチャの場合はその性質上、各々のサービスが一つの モジュールとなるのが基本です。 仮にモノリスとして開発した場合は 図2.2.4 のように注文、在庫、出荷がそれぞ れモジュールとしてまとめられるでしょう。 モジュール間の連携方式（API連携なのか、メッセージングなのか）なども決める 必要があります。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
48. アーキテクチャ設計 マイクロサービスアーキテクチャのようなシステム全体の構造や、レイヤードア ーキテクチャのようなアプリケーションの基本構造を検討し決定します。その他 にも、下位の設計に影響を与えるようなシステム全体の思想や方針を定めること もアーキテクチャ設計の一部です。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
49. アーキテクチャ設計の例 注文、在庫、出荷をそれぞれマイクロサービスとするシステム構成や、サービス 間の連携方式を定めます。また、それぞれのサービスの内部構造としてはレイヤ ードアーキテクチャを採用する方針としています 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
50. 設計の大事さ 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
51. 設計が良くなかった場合 小規模な組織なのにマイクロサービスを取り入れた 単純な機能を作るためにサービス間のAPIを作るオーバーヘッドが生まれた null許容したくないカラムに対してDBレベルで制約をつけなかった アプリでそのカラムを使う時にnullじゃないかいちいち確認しないといけない モダンな技術を使ったが、ユーザーが伸びずメンテされなくなってしまった セキュリティホールが生まれた 依存関係により他のライブラリのアプデを妨げる Developerを採用できない 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
52. その時点で最適な設計をしよう（当たり前） 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計
53. ただ、良い設計をするには現状（As is）の把握が強固である事が前提なので、 その部分を疎かにしないようにしたいと思いました。 2.1　ソフトウェア開発プロセス 第２章 ソフトウェア設計