オブジェクト指向開発論

オブジェクト指向開発論

2016年6月25日 土曜 補講1/2

海谷 治彦

目次

パターン その2 • パターンの分類 • デザイン以外のパターン • パターンと品質要求 • セキュリティパターン: 例題として • デザインパターンその2 2

パターンの分類

• デザインパターンの分類 • 代表的なパターンを，その範囲と利用目的の二軸で分 類している． • 抽象度に基づく分類 • アーキテクチャ，要求分析，デザイン，コーディング等そ れぞれのパターン． • 品質特性に関する分類 • セキュリティ，ユーザビリティ等 3

デザインパターンの分類

4 目的 生成 構造 振る舞い 範 囲

クラス Factory Method Adapter Interpreter

Template method インスタンス Abstract Factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Proxy Chain of responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

抽象度に基づく分類

• アーキテクチャパターン • システム全体の構成に関するパターン • MVC や REST 等． • アナリシスパターン • 要求分析における分析対象業務の典型的な様式． • デザインパターン • 本講義のメイン • イデオム • コーディング(プログラミング)における典型的なコードの 書き方． • コーディング規則のことではない． 5

品質特性

• ソフトウェアや情報システムは，それらが提供する 機能に加え，期待される品質特性がある． • 例えば，銀行等の入出金機能は，「正確」かつ「高信頼 性_{」(故障が無い)であることが期待される．} • スマフォ等のソフトでは，例えば電池の持ちが良い等の 「パフォーマンス」も期待される． • これら品質特性は，往々にして，設計やアーキテ クチャ決定に大きく依存する． • パターンというのは，広い意味で，ある品質特性を 担保しやすくする設計，実装の定石ともいえる． • 前回，紹介したデザインパターンは，拡張性という品質 に注目している． 6

品質特性とは？

• いくつかの異なる標準規格や，著書等で，いくつか の品質特性のカタログが提示されている． • しかし，そのほとんどは大きな違いは無い． • ISO9126 • IEE830 • FURPS+ • NFR framework 7

8

ソフトウェア品質特性標準

– ISO 9126

• ソフトウェア品質特性に関する標準 • http://www.cam.hi-ho.ne.jp/adamosute/software-quality/iso9126.htm より

9

ソフトウェア品質特性標準

– IEEE 830-1998

• ソフトウェア要求仕様に対する推奨プラクティス • 「3.6 Software system attributes」にて、ソフトウェア

品質特性を規定 • 信頼性(Reliability) • 可用性(Availability) • セキュリティ(Security) • 保守性(Maintainability) • 移植性(Portability)

10

分析観点の例： FURPS+モデル

• Grady, “Practical Software Metrics for Project

Management and Process Improvement” (Prentice-Hall, 1992)

• http://www.atmarkit.co.jp/farc/rensai/re_mgt02/re_ mgt02.html より

11

NFRの型

NFR型 効率 _コスト ユーザー親和性 セキュリティ Confidentiality Integrity Availability Accuracy Completeness 時間 空間 レスポンス スループット プロセス管理時間 主記憶 補助記憶

セキュリティパターン

• 拡張性以外のパターンの例

• 情報システムやソフトウェアが持つ機能をセキュア にするための設計等の定石である．

• セキュア: Confidentiality, Integrity, Availability (機 密が守られる，不正改竄されない，使いたい人が いつでも使える)

• 要求分析，設計，実装，テストそれぞれのセキュリ ティパターンがあるようだ．

Role based Access Control

• 役割に応じて，対象物に対して，限定的なアクセス 型を提供する． 13 - name : NAME - id : ID User - name : NAME - id : ID Role - name : NAME - id : ID ProtectionObject MemberOf Right + checkRights() : boolean - accesstype : AccessType Right

セッションの管理

• 話としては，User が Component をアクセスするだ け． • しかし，事前にログイン等を行なった User のみに Component のアクセスを限定するため，Session を 作成および破棄する機構が組み込まれている． 14 User

+ logoff(sid : SessionId) : void + login() : SessionId

CheckPoint

+ release(sid : SessionId) : void + verifySID(sid : SessionId) : boolean + newSession() : SessionId

Manager

+ doSomething(sid : SessionId) : void Component

+ getUserInfo() : User Session

動作シーケンス

15 : Session : Component : Manager : CheckPoint : User 1: login() : SessionId 1.1: newSession() : SessionId <<create>> 1.1.1: Createメッセージ() 2: doSomething(sid:SessionId) : void 2.1: verifySID(sid:SessionId) : boolean 2.2: getUserInfo() : User 3: logoff(sid:SessionId) : void 3.1: release(sid:SessionId) : void <<destroy>> 3.1.1: Destroyメッセージ()

セキュア ロガー

• セキュアに動作記録(ログ)を保持するための設計 パターン． 16 クライアント SecureLogger LogManager Factory Logger use use use use create SecurePipe SecureStore use store

デザインパターンの実例

第二弾

コンポジット

• Composite • 階層構造，木構造を表現する強力なパターン． • 例えば，OSのファイルシステムの構造，組織の階 層等． • 多分，階層構造を表現するこれ以上良い方法は 無い． 18

一般的な表現

• ファイル構造を例にとれば，Leaf がファイル， Composite がフォルダ(ディレクトリ)に相当． • 無論，適宜，メソッド等を追加してよい． 19 クライアント + operation() : void <<abstract>> Component Leaf

+ get(id : int) : Component + size() : int

+ remove(child : Component) : Component + add(child : Component) : boolean

ファイルシステムの例

• UNIX風のコマンドをメソッドとして実装． • 実際，UNIXでは，ファイルとフォルダの作成，削 除のコマンドが異なるため，それも準拠． 20 クライアント <<abstract>> Component + emacs() : void + cat() : void File

+ cd(fol : Folder) : boolean + rm(file : File) : boolean + rmdir(fol : Folder) : boolean + touch(name : String) : File + mkdir(name : String) : Folder

インスタンスの例

21 / : Folder etc : Folder fstab : File home : Folder

kaiya : Folder k-matsui : Folder

fork1.c : File nantoka.mp4 : File crypto.c : File Crypto.java : File

クライアント <<abstract>>

Component

+ emacs() : void + cat() : void

File

+ cd(fol : Folder) : boolean + rm(file : File) : boolean + rmdir(fol : Folder) : boolean + touch(name : String) : File + mkdir(name : String) : Folder

Folder

アダプター

• Adapter • 既存のクラス群に対して，ある統一した処理を施し たいが，それぞれメソッド名がばらばらであったり， そもそも，一つのメソッドで実現されてなかったりす る場合がある． • それを統一して扱うための「アダプター」を，それぞ れのクラスにかぶせるためのパターン． 22

例

• 例えば，OSに接続されている，HD, SSD, CD, DVD, USBメモリ等は実際にはデータの読み書き の処理内容はばらばらである． • これらを統一して扱うためのパターンが以下． 23 クライアント

+ read(name : String) : File

+ write(file : File, name : String) : boolean <<interface>> InputOutput + hdread() : void + hdwrite() : void HD + ssdread() : void + ssdwrite() : void SSD + dvdread() : void DVD HDAdapter SSDAdapter DVDAdapter

一般形

• Target: アタプターを規定するインタフェース • Adaptee: アダプターをとりつける既存クラス • Adapter: Targetに基づき作成されたアダプター 24 クライアント + request() : void <<interface>> Target + request() : void Adapter + specificRequest() : void Adaptee specificRequest が中で 使われているでしょう．

コマンド

• Command • GUIアプリのメニューにあるようなコマンド選択肢 自体を独立したオブジェクトとして扱う設計． • 操作履歴を容易に残せるため，undo 等の実装も 容易． • また，操作対象(例えば文書ファイル等)の挙動が 遅い場合でも，コマンドを待ち行列に保持すること ができる． • 結果の反映が遅くても，コマンド自体は入力できる． 25

設計の例

• 簡単な文書エディタ • Copy: 文書.get()を呼んで，現在の文字を取得． • バッファーに取得したものを保持． • Paste: バッファーからstrを取得． • 文書.insert で文書に追加． • Move: 文書.moveCursor でカーソル移動． 26 - queue : コマンド[] メニュー <<abstract>> + execute() : void コマンド Copy Pasete Move + get() : String

+ insert(str : String) : void

+ moveCursor(location : int) : void - contents : String

- location : int 文書

- buf : String バッファー

一般形

• Invoker: メニュー等に相当 • Command: コマンド一般を指す • ConcreteCommand: 具体的な個々のコマンド • Receiver: 実際にコマンドが適用されるデータ等 27 クライアント Invoker <<abstract>> + execute() : void Command + execute() : void ConcreteCommand + action() : void Receiver - receiver <<create>> receiver.action()

ファサード

• Façade • サブシステムにまとめたクラス群への窓口を一手 に引き受けるクラスを導入すること． • これによって，サブシステム内の構造を変更しや すくなる． • 名前は建物のファザードに 由来するらしい． 右記のような感じ． 28

設計の例

• 学生の成績を管理するクラス群にアクセスするクライ アントアプリを考える． • ここのクラスに直接アクセスするのではなく，サブシス テムの代表をするクラスを導入する． • 後に，学生成績のドメインモデルに変更があっても，ク ライアントへの影響は少ない． 29 クライアント 成績管理 学生 科目 成績 教員 教室 成績Facede

一般形

• 尚，UMLにはサブシステムとパッケージがあり， 前者はクラス等との関連が持てる点で後者と異な る． 30 クライアント サブシステム0 Facede サブシステムのクラスA サブシステムのクラスB

ステート

• State • オブジェクトの状態が変化した際，その振る舞いが 変化することをデザインしたい． • 単純にオブジェクト内に多数の条件分岐を書くの ではなく，状態毎にクラスを定義し，その振る舞い をクラス毎に記述してゆくデザイン手法． • 多数の条件分岐があるより，多少見やすいかも． 31

設計の例

• ニートじゃない人は，平日と週末では反応が違うだろう． • 例えば，週末午前に「おはよう」といっても寝てるかもしれな い． • また，平日午後に「良い午後だね (Good afternoon)」といっ ても，「ちくしょう (Shit)」といってくるかもしれない． 32 クライアント + setMode() : void PersonReaction + goodAfternoon() : void + goodMorning() : void <<interface>> ReactionMode + goodAfternoon() : void + goodMorning() : void WeekdayMode + goodAfternoon() : void + goodMorning() : void WeekendMode おはよう Shit! zzz.... おーす，元気～

一般形

• Stateが状態によって変化する振る舞いのリストに相当． • ConcreteStateA, Bで，実際，個々の異なる振る舞いを 規定． • クライアントは Context にアクセスし，その時のStateに 依存した振る舞いを返す． 33 + request() : void Context <<interface>> + handle() : void State + handle() : void ConcreteStateA + handle() : void ConcreteStateB - state クライアント state.handle();

オブザーバー

• Observer • あるデータを持つオブジェクトAと，そのデータに依 存する他のオブジェクトX,Y,Zがあるとする． • このAを Subject と呼ぶ． • X,Y,Zを Observer とそれぞれ呼ぶ． • Aの変化にX,Y,Zが自動的に追従する仕組みをう まく実現する定石のデザイン． • Observerを途中で追加，削除できるのでとっても便 利． 34

設計例

• 右のように，表データを 多様なグラフで表現す るとする． • データが変化するとグ ラフもそれに追従する． 35 A 50 B 30 C 20 円 A B C 0 10 20 30 40 50 60 A B C 折れ線 0 100 A B C 棒 + getStates() : int[] - C : int - B : int - A : int 表データ + notify() : void

+ detach(o : Observer) : void + attach(o : Observer) : void - observers : Observer[]

Subject

+ setSubject(s : Subject) : void - subject : Subject + update() : void <<abstract>> Observer 折れ線グラフ 棒グラフ + update() : void 円グラフ subject=s o.setSubject(this) で， Observer側にsubjectを登録も する． for(o in observers) o.update(); subject.getStates() で値 群を取得．描画． 他も同じ．

シーケンス図

36 : 折れ線グラフ : 表データ 1: attach(o:Observer) : void 1.1: setSubject(s:Subject) : void observerの登録， 他のグラフも同様 : 棒グラフ : 円グラフ クライアント : 表データ : 折れ線グラフ 1: notify() : void 1.1: update() : void 1.1.1: getStates() : int[] 1.2: update() : void 1.2.1: getStates() : int[] 1.3: update() : void 1.3.1: getStates() : int[] アップデートの様子 + getStates() : int[] - C : int - B : int - A : int 表データ + notify() : void + detach(o : Observer) : void + attach(o : Observer) : void - observers : Observer[]

Subject

+ setSubject(s : Subject) : void - subject : Subject + update() : void <<abstract>> Observer 折れ線グラフ 棒グラフ + update() : void 円グラフ subject=s o.setSubject(this) で， Observer側にsubjectを登録も する． for(o in observers) o.update(); subject.getStates() で値 群を取得．描画． 他も同じ． 参考

一般形

37

- os : Observer[]

+ notify() : void

+ detach(o : Observer) : void + attach(o : Observer) : void

Subject

+ update() : void <<abstract>>

Observer

for(o in os) o.update();

- s : State + getState() : void ConcreteSubject + update() : void ConcreteObserver - subject subject.getState() を利用

デザインパターンの分類

38 目的 生成 構造 振る舞い 範 囲

クラス Factory Method Adapter Interpreter

Template method インスタンス Abstract Factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Proxy Chain of responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

午後に続く