DevLOVE関西 現場のアーキテクチャの話をしてみませんか？ のセッション資料です。

2. 自己紹介
Name
Job
Skill
Community
Shinichi Kozake
Systems Architect
Java
関ジャバ/Hoge Driven

3. 自己紹介
!
certificate
!
Project
Application Systems Engineer
Database Systems Engineer
挑め！稼働率99.99%
大規模！警報管理システム
レガシーからAndroidまで！
大規模！保守点検サポートシステム

4. アーキテクチャとは
フレームワークとは
システム設計について
まとめ
Agenda

5. アーキテクチャとは
フレームワークとは
システム設計について
まとめ
Architecture

6. アーキテクチャってなに？

7. Architecture
システムの特徴を現すもの
システム構造
システム特性
・動的
・静的
・振る舞い
・品質特性
7

8. システム構造
システム特性
Architecture
システムの特徴を現すもの
・動的
・静的
・振る舞い
・品質特性
アーキテクチャとは
システム特性やシステム構造など、
そのシステムの特徴を現すものです。
文書の有無や優劣はともかく
どんなシステムにも
アーキテクチャは存在します。
8

9. Architecture
システムの特徴を現すもの
システム構造
システム特性
・動的
・静的
・振る舞い
・品質特性
!
これらを
アーキテクチャ設計書として
ドキュメントで現します。
9

10. システム構造
システム特性
Architecture
システムの特徴を現すもの
・動的
・静的
・振る舞い
・品質特性
!
システムの外部から見て分かる振る舞いです。
提供する機能、外部環境やシステムとの
相互関係などについて定義します。
!
・アクティビティ図
・ユースケース図
・ボックス＆ライン図
10

11. システム構造
システム特性
Architecture
システムの特徴を現すもの
・動的
・静的
・振る舞い
・品質特性
!
性能要件、システム稼働率、セキュリティなど、
いわゆる非機能要件といわれる
システムの品質特性を定義します。
!
・システム品質要件
→ 主に文章で現します。
11

12. システム構造
システム特性
s
Architecture
システムの特徴を現すもの
・動的
・振る舞い
・品質特性
・静的
!
システムの静的構造について、
各要素とそれの関係を定義します。
!
・クラス図
・コンポーネント図
・配置図
・ER図
・ボックス＆ライン図
12

13. システム構造
システム特性
Architecture
システムの特徴を現すもの
・静的
・振る舞い
・品質特性
・動的
!
システムの動的構造について、
ある時点の実行時の要素と相互作用を定義します。
!
・シーケンス図
・フローチャート
・ステートチャート図
13

14. どんな観点で検討するのか？

15. Architecture
様々な視点
機能的
情報
並行性
開発
配置
運用
15

16. Architecture
様々な視点
機能的
情報
並行性
開発
配置
運用
!
システム要素の機能・責務・関連システム
とのインタフェースや相互作用など
アーキテクチャを示す上で一番重要な影響を与えます。
!
＜システム要素とは＞
システム/サブシステム/ソフトウェア製品/モジュール/クラス
など、システムを構成する要素のこと
16

17. Architecture
様々な視点
機能的
情報
並行性
開発
配置
運用
!
システムが扱う情報そのもの
格納・操作・管理方式
データの特性や構造、関係、データ移動やそれに関する問題など
17

18. Architecture
様々な視点
機能的
情報
並行性
開発
配置
運用
!
システムの並行処理に関する技術方式
並行実行の調整や制御方式
18

19. Architecture
様々な視点
機能的
情報
並行性
開発
配置
運用
!
開発方式
パッケージ構成/モジュール管理/標準ガイドライン/
テスト方式/ソース管理/デプロイ方式/開発ツール/
適用ライブラリ/etc
!
19

20. Architecture
様々な視点
機能的
情報
並行性
開発
配置
運用
!
システムの配置環境
ハードウェア環境やネットワーク環境などの物理制約や
ハードウェア配置場所の格納問題など
!
検討する項目はハードウェアの重量から
データセンターの制約まで様々ありますが
見積もりの問題などから不確定要素の多い初期段階で
方式検討と確定が行われやすい傾向があります。
20

21. Architecture
様々な視点
機能的
情報
並行性
開発
配置
運用
!
システムの運用/管理/サポートラインの確立など
システム監視方法や障害発生時の解析手順、
システムやデータの移行方式、バックアップ/リストア手順など
システム運用後に発生する様々なシナリオに対する方式
21

22. Architecture
様々な品質特性
セキュリティ 性能 可用性 発展性
22

23. Architecture
様々な品質特性
セキュリティ 性能 可用性 発展性
!
セキュリティガイドラインへの準拠
情報リソースへのアクセス管理/権限/監視の必要性
23

24. Architecture
様々な品質特性
セキュリティ 性能 可用性 発展性
!
システムの性能要件
!
スループットや応答時間
スケール方式
ピーク負荷に対する対策など
24

25. Architecture
様々な品質特性
セキュリティ 性能 可用性 発展性
!
システムの可用性要件
!
システム稼働率
計画停止時間
障害回復時間
など
25

26. Architecture
様々な品質特性
セキュリティ 性能 可用性 発展性
!
システムの変更に対する柔軟性
!
開発やデプロイの容易性
各環境や技術への依存度合いの考慮
知識の保存を見越した技術選択
など
26

27. Architecture
様々な視点と品質特性
機能的
情報
並行性
開発
配置
セキュリティ 性能 可用性 発展性
運用
27

28. Architecture
様々な視点と品質特性
機能的
情報
並行性
開発
配置
セキュリティ 性能 可用性 発展性
運用
!
品質特性はそれぞれの視点にわたり関連します。
各視点において品質特性を考慮した方式を取捨選択します。
!
28

29. Architecture
様々な視点と品質特性
機能的
情報
並行性
開発
配置
セキュリティ 性能 可用性 発展性
運用
!
認証方式
暗号化方式
29

30. Architecture
様々な視点と品質特性
機能的
情報
並行性
開発
配置
セキュリティ 性能 可用性 発展性
運用
!
守るべき情報リソースの定義
30

31. Architecture
様々な視点と品質特性
機能的
情報
並行性
開発
配置
セキュリティ 性能 可用性 発展性
運用
!
スレッド制御方式
ロック制御方式
31

32. とある現場の品質要件

33. ・システムの稼働率は99.99%
障害によるシステム停止許容時間は10分以内
Architecture
・装置から受信した警報のモニター画面表示は受信後
1分以内に行われる事
・インターネットに繋がるWebシステムについては
弊社規定のセキュリティガイドラインを満たすこと
・システム移行によるシステム停止は認められない
現行システムで保有する億件データも移行対象
品質要件
33

34. ・システムの稼働率は99.99%
障害によるシステム停止許容時間は10分以内
Architecture
・装置から受信した警報のモニター画面表示は受信後
1分以内に行われる事
・インターネットに繋がるWebシステムについては
弊社規定のセキュリティガイドラインを満たすこと
・システム移行によるシステム停止は認められない
現行システムで保有する億件データも移行対象
品質要件
管理
番号
優先度
a-1
a-2
a-3
a-4
A
A
A
A
34

35. Architecture
・システムの稼働率は99.99%
障害によるシステム停止許容時間は10分以内
・装置から受信した警報のモニター画面表示は受信後
1分以内に行われる事
・インターネットに繋がるWebシステムについては
弊社規定のセキュリティガイドラインを満たすこと
・システム移行によるシステム停止は認められない
現行システムで保有する億件データも移行対象
品質要件
管理
番号
優先度
a-1
a-2
a-3
a-4
A
A
A
A
!
品質要件に管理番号を付与することで、要件管理が明瞭となります。
また、アーキテクチャ方式設計書のドキュメント内での記述が簡潔になります。
!
(例)
品質要件a-1の為、全てのハードウェアについては冗長構成をとる。
これにより、可用性は向上するが、ハードウェアの故障率が増加し、
運用も複雑となる。
!
35

36. Architecture
・システムの稼働率は99.99%
障害によるシステム停止許容時間は10分以内
・装置から受信した警報のモニター画面表示は受信後
1分以内に行われる事
・インターネットに繋がるWebシステムについては
弊社規定のセキュリティガイドラインを満たすこと
・システム移行によるシステム停止は認められない
現行システムで保有する億件データも移行対象
品質要件
管理
番号
優先度
a-1
a-2
a-3
a-4
A
A
A
A
!
品質要件に優先度を定義します。
これにより、アーキテクチャ方式の決定（取捨選択）の際の指針ができます。
!
(例)
品質要件a-1の為、全てのハードウェアについては冗長構成をとる。
これは、品質要件a-xにある運用コストの低減に相反するが可用性の担保
を優先する。
36

37. とある現場の
アーキテクチャモデル

38. Architecture
システム構造
ボックス＆ライン図

39. Architecture
開発環境
ボックス＆ライン図

40. !
ボックス＆ライン図は正確性に欠けるますが、
専門知識の無いユーザに理解しやすいという利点があります。
アーキテクチャ検討初期の段階において、
またはコミュニケーションツールとして便利です。
Architecture

41. Architecture
システム間連携
コンポーネント図

42. Architecture
システム配置
配置図

43. !
一つのアーキテクチャモデルに複数の視点を記述すると
モデルが複雑となり、モデルの正確性や理解性が損なわれます。
１つの視点から１つのアーキテクチャモデルを現すよう
心がけましょう。
Architecture

44. Architecture
アーキテクチャとはシステムの特徴を現すもの
図表や文章を用いてシステム構造や特性を現す
アーキテクチャは様々な視点と品質特性から
検討され、取捨選択により決定する
44

45. アーキテクチャとは
フレームワークとは
システム設計について
まとめ
System Structure

46. System Design
システムの３層構造
UI Logic Data
46

47. 各層の特徴
UI Logic Data
理解の容易さ理解しやすい 理解しにくい
System Design
47

48. 各層の特徴
依存性の方向依存する 依存しない
UI Logic Data
理解の容易さ理解しやすい 理解しにくい
System Design
48

49. 依存性の方向依存する 依存しない
UI Logic Data
各層の特徴
!
UIは理解しやすく、ユーザの要望を捉えやすいです。
そこで、画面イメージやプロトタイプをもとに要件定義を進めると
早期の段階でユーザ要望を適切に把握することが出来ます。
理解の容易さ理解しやすい 理解しにくい
System Design
49

50. 理解の容易さ理解しやすい 理解しにくい
UI Logic Data
各層の特徴
!
一方、データ構造とその関連はユーザには理解しにくいです。
しかし、この層の変更は全ての層に対して影響を与えます。
データ構造および関連を正確に設計することがシステム開発の
肝となります。
依存性の方向依存する 依存しない
System Design
50

51. 各層の特徴
変化の流れ変化しやすい 変化しにくい
UI Logic Data
System Design
51

52. とある現場の技術変化
JSP iBatis
Flex myBatis
Android myBatis
Java Logic
Java Logic
Java Logic
Struts
BlazeDS
JAX-RS
2014∼2015
2011∼2013
∼2010
System Design
52

53. iBatis
myBatis
myBatis
Java Logic
Java Logic
Java Logic
とある現場の技術変化
JSP
Flex
Android
Struts
BlazeDS
JAX-RS
2014∼2015
2011∼2013
∼2010 UI層に近づくほど
技術変化が激しいです。
UI層とロジック層を分離した
方式設計を心がけると変更に
強いシステムになりやすいです。
System Design
53

54. システムを層に分けて捉える
各層の特性に応じて方式を設計する
UI層は柔らかい技術
ロジック・データ層は固い技術を
System Design
54

55. アーキテクチャとは
フレームワークとは
システム設計について
まとめ
Framework

56. Framework
User
App
Framework
Library
Register
Call
Call
Callback
・ライブラリは呼び出すもの
・フレームワークは呼び出されるもの
56

57. Framework
User
App
Framework
Library
Register
Call
Call
Callback
!
「ハリウッドの原則」
!
私たちを呼ぶな、私たちがあなた方を呼ぶ
（Don't call us. We'll call you）
57

58. 型にはめることで効率化
Framework
・強力なフレームワークは適用範囲が狭い
・適用範囲が広いと、強力さが失われる
58

59. Framework
Framework
User Framework
Library
User
App
59

60. Library
User
App
Framework
Framework
User Framework
!
frozen spot
!
hot spot
60

61. Framework
Framework
Library
User
App
User Framework
!
適用フレームワークでカバーが出来ない業務要件について
業務要件に特化したフレームワークを構築します。
いわゆるオレオレフレームワークと呼ばれています。
オレオレフレームワークは存在そのものが悪いのではなく、
その品質が一般的に悪いのが問題です。
61

62. Framework
Framework
Library
User
App
User Framework
!
業務フレームワークはある業務要件に特化したものなのです。
それを別の業務要件に再利用しようとすると、
適用範囲の相違による非効率さが発生しやすいです。
62

63. User Framework
Framework
Library
User
App
User App
Framework
!
業務フレームワークで業務要件を
全てカバーしようとするのは悪手です。
２割の労力で８割の処理が楽になる感覚で設計しましょう。
残り２割は業務フレームワークのサポート対象外にしたほうが
複雑性が低減します。
63

64. フレームワークは型にはめることで効率化を計る
業務要件に特化したフレームワークの構築を
64
Framework
全ての業務要件をフレームワークでカバーしない
２：８の原則を

65. アーキテクチャとは
フレームワークとは
システム設計について
まとめ
Summary

66. Summary
アーキテクチャとは
フレームワークとは
システム設計について
!
あっちを立てればこっちが立たず

67. Summary
アーキテクチャとは
フレームワークとは
システム設計について
!
レイヤーという響きがいいよね？

68. Summary
アーキテクチャとは
フレームワークとは
システム設計について
!
オレが、オレこそが
真のフレームワークだ!!!
(((o(*ﾟ▽ﾟ*)o)))

69. DevLove!

70. Thank you!