More Related Content
Similar to 設計品質とアーキテクチャ (20)
More from Toru Koido (12)
設計品質とアーキテクチャ
- 2. 自己紹介
仕事
プログラマー(1984年から)
業務パッケージシステムを開発(1984年から)
具体的な作業内容
開発のガイドラインを作る
開発プロセスを設計する
開発プロセスを支える環境を構築し、運用する
各種ツールの選択
自動化や支援ツールの開発
ビルド環境の整備、各種管理ツールの整備
ソフトウェア・アーキテクチャを決定する
基盤フレームワークの設計と実装
基盤の共通ライブラリの設計と実装
開発上のいろいろな相談を受ける
コミュニティ
XPJUG、SQiP(日科技連)、過去MS-MVP、MS-RD
2
- 12. 12
設計とは
設計の難しさ
利用者の視点から開発者の視点へ
視点変換によってギャップの発生(間違える)
複数のステークホルダ
利用者、開発者、運用担当者など
相反する要求項目
パフォーマンスとセキュリティなど
予測することが難しい要求の変更や機能強化
利用者:XX機能が必要 開発者:作りやすくしたい
運用担当:メモリ使用量は少なく
- 13. 13
悪い設計 もろさ
もろさ
1つの変更により、論理的には関連のな
い箇所まで正常動作しなくなる
扱いにくさ
正しいことをすることが難しいシステム
硬さ
変化しにくいシステム
1つの変更が全体に影響し、多くの変更
が必要になる
- 14. 14
悪い設計 不透明さ
不透明さ
読みにくく、わかりにくい
不必要な複雑さ
本質的に意味を持たない構造が含まれているシステム
不必要な繰り返し
同じような構造が繰り返し現れ、共通化できる部分がされて
いない
移植性のなさ
再利用できる部分を
切り出すことができない
- 15. 15
良い設計とは(設計品質特性)
正確性
仕様を正しく満たしていること
理解性
設計結果が読みやすく理解しやすいこと
一貫性(統一性)
設計上の個々の概念が首尾一貫して、ぶれがない
変更容易性
機能強化などに伴う変更が容易であること
頑健性(ロバストネス)
誤った使い方に対して、システムが適切に対処できること
システムの一部のバグが全体に波及しないこと
移植性
いろいろなハードウェア、ソフトウェア環境へ容易に移植できること
効率性
実行効率、資源効率ともに十分実用に適応していること
- 18. 18
設計品質特性 正確性
正確性とは
仕様を正しく満たしていること
ポイント
設計の論理的な領域で検証する
仕様(論理的な領域)をマップした領域と実装領域を分離する
レビューを受ける
レビュー者に分かる設計にする
– 言葉が大切である
– ドメインの単語を利用する
テストの役割
テストによって仕様を満足していることを確認する
論理的な視点で検証を行う
テストの視点は、論理的な側面からの視点である
- 19. 19
設計品質特性 理解性
理解性とは
さまざまな関係者が設計の結果を十分理解しやすいこと
ポイント
論理的側面の設計によって理解しやすくなる
既に理解している概念を利用する
現在使用している単語を利用する
知っていることをメタファ(比喩)として利用する
統一された言葉を利用している
同じ単語が同じ概念で利用されている
テストの役割
テストによって処理の流れを明示して、
理解を助ける
テストは使い方なので、使うことで理解が進む
中だけ見ても?
- 20. 20
設計品質特性 一貫性(統一性)
一貫性とは
設計上の個々の概念が首尾一貫していること
ポイント
粒度を合わせる
モジュールやAPIなどの粒度を合わせることで一貫性が生まれる
階層化する場合、階層内では粒度を合わせる
統一した概念や名前を使用する
テストの役割
利用者の視点から粒度の確認を行う
統一性のチェックには、
利用者からの視点が有効である
並べて粒度を比較
- 21. 21
設計品質特性 変更容易性
変更容易性とは
機能強化などに伴う機能追加や変更が容易であること
ポイント
以下の2つの設計方法を状況に応じて実施する
変更を予測した設計を行う
変更に合わせて再設計(リファクタリング)を行う
–変更しやすいように設計を変更する
テストの役割
テストによって、変更の影響が波及していないことを確認す
る
再設計(リファクタリング)の実施にはテストが必要
再設計によって、既存の機能が正常に動作することをテストによっ
て確認する
- 22. 22
設計品質特性 頑健性(ロバストネス)
頑健性とは
誤った使い方に対して、システムが適切に対処できること
システムの一部のバグが全体に波及しないこと
ポイント
システムの各サブシステム間を密結合としない
サブシステムが独立して動作するようにする
テストの役割
テストによって、頑丈なシステムであることを確認する
エレベーターはワイヤーが
切れたら止まる設計
- 23. 23
設計品質特性 移植性
移植性とは
いろいろなハードウェア、ソフトウェア環境へ容易に移植で
きること
ポイント
再利用できる部分が切り出されている
環境に依存する部分としない部分を分離する
環境に依存しない部分が依存する部分に依存していないこと
自動テストも移植する
テストの役割
テストによって、環境の影響を確認する
テストによって、移植の検証を行なう
- 24. 24
良いテストの条件
テスト目的が明確である
何をテストするか明確である
その目的も明確で、更にひとつであること
テストの判定が正しい
テストの成功、失敗が正しく判断されている
テストを独立して実行することができる
テストが他のテストに依存することなく、独立している
繰り返し実行することができる
何度でも繰り返して、テストを実行することができる
テストを実行しても、状態が変化しない
テストを実行し、成功した場合でも失敗した場合でも、テスト
を実行する前と後で何も変わらない
- 28. 28
まとめ 設計の原則
プログラムをモジュールに分割する
分割することで、プログラムが複雑になるのを避ける
モジュール間の依存関係を明確にする
モジュール間の結合度が低い
モジュール間の結合度が低いほうが良い
修正や問題が影響する範囲が少なくなる
モジュールの凝集度が高い
各モジュール内の凝集度を高くすることで、モジュール間の
結合度が低くなる
再利用率
モジュール分割し、モジュール間の結合度を低くして再利用
率を上げる
- 33. 33
3つの自動テスト
システムテストとは
システムが全体として正しく動作することを確認するテスト
自動化のするためのツールが必要
結合テストとは
複数の部品(モジュール)がつながって正しく動作すること
を確認するテスト
変更されやすいUIの影響を受けないテスト
ユニットテストフレームワークなどで自動テスト化する
単位テストとは
コードレベルの動作を確認するテスト(ユニットテスト)
コンパイラなどでは確認できない内容を限定的に動作させ
て確認するテスト
ユニットテストフレームワークで自動テスト化する
33
- 51. 品質特性の具体化手順
品質特性に対するステークホルダを明確化する
例:拡張性
プログラマの拡張性
利用者の拡張性
目的や達成すべきゴールを具体的に定義する
ポイント
成果物が目的に合っているか、判断できる内容で記述する
例:拡張性
利用者が機能を拡張できるように、外部ファイルに拡張機能を定義
できるようにする
例:ユーザービリティ
5秒以上掛かる処理は、処理の進行状況を通知する
目的やゴールの理由を説明する
51
- 52. 品質特性の分析
4つの視点による分析
センシティビティ分析
品質特性に良い効果を表す仕組み
論理的な根拠
コンフリクト分析
副作用として、他の品質特性に悪い影響を与える制約
論理的な根拠
トレードオフ分析
複数の品質特性間で良い影響と悪い影響ものの優先順位
正当性の根拠
トレードオフ関係表
リスク分析
トレードオフによってサービスレベルが低下する要求品質に対する
リスクを識別し、影響の出る損失
正当性の根拠
52
- 53. イベント駆動とバッチ処理
ビジネスアーキテクチャ
ビジネスの仕組み
イベント駆動によるサービス
要求があった場合にサービスを実行する
イベント駆動の例
銀行の窓口業務、タクシーのサービス
利点
要求された時だけサービスを行うことで運用コストを減らす
バッチ処理によるサービス
事前に決められた計画に沿ってサービスを実行する
バッチ処理の例
ダイヤを決めて運行する電車やバスのサービス
利点
まとめて行うことでコストを減らす
サービスを行う回数を少なくして運用コストを減らす
53
- 56. 56
システムアーキテクチャの定義
システムアーキテクチャの定義
複数の定義が必要
複数の角度からの表現を組み合わせて定義を行う
システム開発のビジョンを実現するために必要なシステム
構造
構造化原則
抽象的な構造やガイドライン
概念的な構造(モデリング)
ANSI/IEEE Std 1471-2000
構成要素を統合したシステムの基本的な構造,構成要素
の相互および構成要素と環境間の関係,そしてシステム設
計と発展を導く方針
全体の分け方と、分けた部分をどのように関係づけるか
- 58. 58
アーキテクチャの複数のビュー
ビューポイントとは
ステークホルダの関心事に応じた視点
ビューとは
複数の関連した視点(ビューポイント)によって、アーキテクチャを記述
するものがビューである
4つのビュー
論理ビュー
システムが必要とされている機能を実現する、論理的な構造
実行ビュー
実行時のプロセスやタスクやスレッドといった実行時の単位の構造
開発ビュー
システム開発時のファイル等を単位とした構造
配置ビュー
システムをどのようなマシン上で動作させ、各プロセスがどのマシン(CPU)
上に配置されるか等を表した構造
- 61. 参考資料2:品質特性 ISO/IEC 25010:2011
システム/ソフトウェア製品品質
機能適合性
機能完全性
機能正確性
機能適切性
性能効率性
時間効率性
資源効率性
容量満足性
互換性
共存性
相互運用性
使用性
適切度認識性
習得性
運用操作性
ユーザエラー防止性
ユーザインタフェース快美性
アクセシビリティ
信頼性
成熟性
可用性
障害許容性(耐故障性)
回復性
セキュリティ
機密性
インテグリティ
否認防止性
責任追跡性
真正性
保守性
モジュール性
再利用性
解析性
修正性
試験性
移植性
適応性
設置性
置換性
61
- 62. 62
参考文献
実践ソフトウェアエンジニアリング ロジャー S・プレスマン
森口 繁一編『ソフトウェア品質管理ガイドブック』日本規格協会(1990)
アジャイルソフトウェア開発の奥義 ロバート・C・マーチン
日経ソフトウェア「正しく学ぶソフトウェア設計」
実践UML パターンによる統一プロセスガイド クレーグ・ラーマン
UMLによる オブジェクト指向モデリング セルフレビューノート 荒井玲子
UML モデリングの本質 児玉公信
テスト駆動開発入門 ケント・ベッグ
ソフトウェアアーキテクチャ 岸知二、野田夏子、深澤良彰
Software Factories ソフトウェアファクトリー Jack Greenfield, Keith Short
リファクタリング プログラムの体質改善テクニック Martin Fowler
IT アーキテクチャ・メタモデル セマンティック解説 ITスキル標準 V2 2006
アーキテクトの審美眼 萩原正義