Transcript アーキテクチャ設計と評価

前回の論点
1. データモデルでオブジェクトモデルとERモデルをどう共存させるか。
 インタフェース情報レベル作成の際に、対応するERモデルも作成し、非機能要件
も考慮した設計となるようにする。
2. DBアクセス性能をどのように担保するか。
 非機能要件、シナリオを定め、それを元にアーキテクチャ評価、決定を行う。
 ドメインモデルパターン（再利用重視）
 トランザクションスクリプトパターン（性能重視）
3. 成果物の作成をどうするか。
 ステートレスなWebモデルを前提として、クラス図などの作成範囲を限定。
 体制モデルを定め、OCLの記述範囲を限定。コミュニケーション目途の文書記述
を減らす。
これを踏まえた予定
1. １イテレーション目はスタンダードなUML Components を適用。まずはドメインモデルパターン ＋
オブジェクトモデリングで実施。
評価観点
 スタンダードな非機能要件を満たせるか確認。特にアクセス性能など。
 ステートレスなWebアーキテクチャで繰り返し作業となっている部分を抽出し、作業軽減
の方法を検討する。
 その他の改善点を抽出する。
2. ２イテレーション目で非機能要件を考慮したUML Components適用、及び、作業省略などの上で
実施する。
評価観点
 １イテレーション目と比べて、非機能要件への対応状況を確認する。
 作業軽減した結果の効率化の程度を図る。
 SIへの現実適用に向けて、ヒントとして得られた部分と、今後の課題を示す。
システムアーキテクチャ
Webブラウザ
ターゲットとするプロダクト
HTTP
BTS
Mantis Bug
Tracker
1.2.3
SCM
Apache
Subversion
1.6.13
アプリケーション
サーバ
JDBC
Type4
DBサーバ
※Webサーバ、冗長化、SSL対応などは将来的に対応
ソフトウェアスタック
DBサーバ
クライアント
FireFox 3.6
Internet Explorer 8
PostgreSQL 8.4
Windows XP
CentOS 5.5
アプリケーションサーバ
オンライン
アプリケーション
ライブラリ
Apache POI/log4j
フレームワーク
SAStruts/S2JDBC/Seasar2
Tomcat6.0
バッチアプリケーション
JavaVM6.0
JavaVM6.0
CentOS 5.5
ソフトウェアアーキテクチャ
・画面入力項目
・入力チェック
SAStruts
JSP
N1
S2JDBC
システム
IF
Form
Facade Logic
0…1
1
ビジネス
IF
・導出項目
・区分値（定数）
・拡張プロパティ
Entity
Table
1 1
1
<<DI>>
1
<<DI>>
Action
・ユースケースと1:1
・実行メソッド
・Service呼び出し
・画面遷移
・セッション管理
1
N
<<DI>>
<<DI>>
<<DI>>
<<DI>>
0...1
Service
<<DI>> <<DI>>
N
DTO
・画面出力項目
（読み取り専用プロパテ
ィ）
・JSPと1:1＋α
プレゼンテーション層
1 1
Helper
・Entityと1:1
・DBに関するロジック
・ビジネスロジック
・DTOと1:1
・データ変換
ビジネス層
インテグレーション層
データソース層
参照方向
外部接続アーキテクチャ
BTS
Adapter
ビジネス
IF
Logic
・・・・省略・・・・・・
BTS
<<DI>>
<<DI>> <<DI>>
<<DI>>
SCM
Adapter
SCM
プロダクトが変わっても
設定でアダプタを差し替えること
で対応可能にする。
プレゼンテーション層
ビジネス層
インテグレーション層
データソース層
参照方向
体制モデル
業務開発
ユースケース
グループ
A
ユースケース
グループ
B
堀切
陣内
ユースケースで分割する
（レイヤーでは分けない）
アーキテクチャ
共通機能
システム基盤
開発管理
堀切
陣内
陣内
開発環境
リポジトリ
ビルドサーバ（オプション）
？？
Webサービス（Sourceforge）
開発資材用
SCM
単体試験環境
CIサーバ
（Hudson）
BTS
開発者PC
デイリービルド／自動試験
アプリケーション
サーバ
DB
サーバ
結合試験環境
VM（いずれかのクラウド上）AWS？eclud？
Windows
Windows
XP/Vista/7
アプリケーション
サーバ
Cent OS 5.5
Eclipse
・WARプロジェクト
・JARプロジェクト
Maven2
DB
サーバ
接続試験用
SCM
想定するハードスペック
？
品質シナリオ（非機能要件）
番
号
シナリオ全体
品質特性
刺激
応答
S1
オンライン処理の通常負荷（最大50ユーザ多重、 性能
5アクセス/秒）において、「～」ユースケースの「～
検索操作」でレスポンスタイム5秒以内を実現する。
～ユースケース
の～操作を実
施。
レスポンスタイムが
5秒以内。
S2
DB構造はデータ追加／更新／削除に対するテー
ブルの影響範囲が小さいこと（データ配置が適正
に分散されている）。
変更容易性
データ追加
影響するテーブル
の数が少ないこと
S3
アーキテクチャの各レイヤ、クラスの責務が明確
で、変更要求に対する変更箇所の把握が容易な
こと
変更容易性
仕様変更要求
容易に変更箇所を
特定できること。
S4
SCM、BTSは将来、差し替え可能なこと。
変更容易性
対応プロダクト
追加
設定ファイルにて容
易にプロダクトを差
し替え可能なこと
S5
ビジネスインタフェースは同じデータを扱うユース
ケース間で再利用可能であること。
再利用性
新機能の追加
既にあるビジネスイ
ンタフェースを用い
て少ないコストで開
発可能なこと
S6
いずれのJavaクラスもJunitで単体テストを自動実
行できること。
テスト容易
性
単体テストの作
成～実施
単体テストクラスの
作成、実施が可能
であること
従来のSIで重視されている要素
コンポーネントベース開発によって向上する要素（本質的にはSIでも追求すべき要素だがなおざりにされてきた）
品質シナリオへのアーキテクチャ上の決定
別紙「アーキテクチャ評価.xls」を参照