SSブログ

調べもの:QoS仕様書の構成 [OCUP&OCRES]

第六版:2009-08-01 18:56:06
第五版:2009-07-28 21:32:29
第四版:2009-07-27 23:00:19
第三版:2009-07-26 07:59:45
第二版:2009-07-25 23:09:53
初出:2008-03-02 22:41:33

OCRESの学習中。

この仕様書の内容は、ほかの仕様書に比べてわかりやすいな~。
扱っている内容が組み込みよりビジネス的な話に近いからかなから。

「OCRES Certification Coverage Map」
http://www.omg.org/ocres/coveragemap.htm

「UML Profile for Quality of Service and Fault Tolerance」
http://www.omg.org/cgi-bin/doc?formal/2005-01-02
さて、QoS のモデルはIntermediateの試験範囲で既に把握されていることを前提に、Advancedではそのモデルを構成する要素について説明しています。
「10 QoS Catalog」では、QoS Catalogの具体的な要素について述べています。
それぞれの要素の中にも種類があるものがあります。ものによっては、構造を持っていてその要素について述べています。

10.2 Throughput Characteristics
ここでは3種類のスループットを具体的なスループットの種類として挙げています。
・input-data-throughputs(bit/sec):入力データの平均到着時間
・communication-throughput(bit/sec):出力データの平均出力時間
・processing-throughput(instruction/sec):平均命令処理時間
10.3 Latency Characteristics
・latency:一般的な遅延時間です。
http://mishika.blog.so-net.ne.jp/2008-02-19
・turn-around:要求されてから応答されるまでの時間。
10.4 Efficiency Characteristics
resource-utilization:リソースの使用状況。具体的な特徴として処理能力、通信、メモリを挙げています。
10.5 Demand Characteristics
resource-utilizationと合わせて使います。リソースへの要求の到着のパターンを示す。
・arrival-pattern
10.6 Integrity Characteristic
完全性
10.7 Security Characteristic
セキュリティでは、3種類挙げています。
・access-control:サービスへのアクセス制御
・protection:不正アクセスまで含めた防御
・safety:セキュリティレベルの品質。安全性。
10.8 Dependability Characteristic
信頼性には、availability, reliability, safety (from a reliability perspective),confidentiality, and maintainabilityが含まれます。広いですね。
Dependencyの障害にはFailureとFault、Errorがあります。
Fault:内部の障害の原因。
Failure:外部環境において観察されるもの。期待動作との違い。(仕様に照らしてではなく、関心(intent)に反するかどうか)
AvailabilityはMTBF,MTTRで計測できます。

Fault-toleranceはReliabilityの問題への解決策です。3つの観点で
• maximum-number-of-faults:数を減らす
• error-processing:エラーハンドリング。検出、ダイアグ、障害の除去。ロールバック、ロールフォワード。
• fault-treatment:障害の扱い。障害診断、安定化。

Reliabilityのタイプの以下の2つです。
Maturity:障害をさけるソフトウェアの能力。
Recoverability:復帰能力。
10.9 Coherence Characteristic
共時性ですね。データの並列処理と一貫性に関する性質です。
観察間隔が提示されています。
10.10 Scalability Characteristic
データの数、規模ですか。最小と最大、cost-per-unitがQoSの次元として示されています。

「11 Risk Assessment」では、
「11.1 Risk Assessment Metamodel」では、IT-Systemのリスクアセスメントを、UMLで表すためのモデルその構成要素を記述しています。
以下の章はそれぞれの要素の定義ですね。
11.1.1 Context
コンテキストのサブモデルを定義しています。サブモデルでは以下の要素で定義されています。
・Stakeholder:ステークホルダ。一般的な利害関係者でとらえても問題なさそうです。
・Policy:ステークホルダにとっての、要求基準ですね。各種観点でとらえることができそうです。
・RiskEvaluationCriterion:リスクが許容できるかどうかのボーダーライン、と捉えられそうです。
・Asset:ステークホルダにとっての価値である特徴、のようです。
・Entity:Assetを担う具体的なもの、でしょうか。
・AssetValue:Assetの値。
・ValueDefinition:リスクアセスメントで扱う値の定義ですね。
11.1.2 SWOT
SWOT分析はリスクアセスメントのコンテキストの一つとして使えます。ここでのSWOT分析は企業レベルで使ってますね。
・EnterpriseAsset:組織戦略における特徴。
・EnterpriseStrength:強み
・EnterpriseWeakness:弱い
・EnterpriseOpportunity:機会
・EnterpriseThreat:脅威
11.1.3 Unwanted Incident
不具合ですね。アセスメントを行うシステムに対して、脅威とぜい弱性がどのように潜在不具合に結びつくか、を示しています。
・Threat:不具合の潜在的な原因のこと。外部(hacker, virus)内部(system failure, disloyal employee)どちらもありえます。
・ThreatScenario:Threatがどのようにして不具合を起こすかのシナリオです。
・Vulnerability:ぜい弱性。ThreatによりAssetを侵害するような弱さ、とのこと。
・UnwantedIncident:不具合。ここではAssetが減る、こと。
・Initiate:不具合が別の不具合を呼ぶ、ということです。
・IncidentScenario:不具合が起きるシナリオです。ThreatScenarioは原因側で、こちらは事象側ですかね。
11.1.4 Risk
・AbstractRisk:一般的なリスクのプロパティ。値など。
・Risk:結果の値、頻度、結果として生じるリスクの値に関連するUnwanted Incident
・RiskTheme:
値で分類されるリスクの分類。
・RiskRelationship:
RiskやRiskTheme間の関係。
・RiskEvaluation:
リスクの評価。
・Consequence:不具合が起きた場合の結果。
・Frequency:発生頻度。発生量。
・RiskValue:
11.1.5 Treatment
リスクの取扱、処置。リスクを低減させるため。1つのTreatmentが複数のシナリオに適用できる。
・Treatment:リスクをもたらすシナリオの取り扱い方法
・TreatmentEffect:TreatmentがRiskの値をどれぐらい減らせるかという能力
・TreatmentEvaluation:TreatmentのTreatmentEffectの割り当て・評価
・RiskReduction:TreatmentEffectの値。Riskがどれぐらい減ったか。
・TreatmentOption:TreatmentとScenarioの関係。Treatmentのオプション。
 -Avoid:回避。シナリオを実行しない。
 -ReduceConsequence:リスクによる生じる影響を減らす。
 -ReduceLikelihood:リスクのFrequencyを減らす。
 -Transfer:生じるリスクを他へ移動する。
 -Retain:リスクをそのままにする。

「11.2 Risk Assessment Profile」では「11.1 Risk Assessment Metamodel」で定義したModelをUMLのProfileを拡張することで再定義しています。
11.2.1 Context
Stakeholder,AssetはUsecase::Actor,Kernel::Classを継承。
Interest:Relationship
Policy,Valuedefinition:QoSCharacteristic
Asset:QoS Value
RisEvaluationCriterion:QoSRequired
11.2.2 SWOT
Classifier。4つの要素はSWOTElement
11.2.3 Unwanted Incident
Threat:Actor
ThreatScenario,IncidentScenario:Usecase
Valunerability:Kernel::Feature
Initiate:Kernel::DirectedRelationship
11.2.4 Risk
AbstractRisk:Usecase。AbstractをRiskとUnwanted Incidentが継承
RiskRelationship:Kernel:Association
RiskEvaluation:Keneal::DirectedRelationship
Consequence,Frequency,RiskValue:QoSValue
11.2.5 Treatment
Treatment:Usecase
TreatmentEffect:Kernel::Class
Avoid, ReduceConsequence, ReduceLikelihood,Transfer, Retain:TreatmentOption継承
TreatmentOption, TreatmentEvaluation:Kernel::DirectedRelationship
RiskReduction:QoSValue
「11.3 Examples」はそのまま実例ですね。
11.3.1 Context
11.3.2 Unwanted incident
11.3.3 Risk
11.3.4 Treatment

12 FT Mitigation Solutions
「12 FT Mitigation Solutions」はFault tolerance、つまり障害許容性を実現するための技術的な解決策を述べている章です。
FT techniques provide support to mitigate the reliability problems
ということで、信頼性に関する問題を低減させる技術だそうです。
"In this specification, we limit the scope of FT to the safety mitigation means. We concentrate our work in the scope of the FT technical solutions, not in safety in general (not in safety assessment and prediction). FT are technical solutions to the reliability requirements. Reliability is a specific QoS Characteristic that we can quantify in different ways."(引用:12 FT Mitigation Solutionsより)

12.1 FT Architectures MetaModel
「12.1 FT Architectures MetaModel」では、その解決策のModelを定義し、そのModel要素を解説しているようです。
Fault Detection.不具合の検出。
• Run-time checks実行チェック。オーバーフローや0除算
• Timing checks,タイミングチェック。Watchdog
• Coding checks冗長性に基づくようなコーディングチェック。
• Functions and software structuresファンクションとソフトウェアの構造。
• Replication checks複数のOutputのチェック

self-protection of FT
Groups.:ソフトウェアの要素の複製はグループを特定する必要がある。要素のグループに関連付けられたFT policyとstyleを持っている。
Replication styles.:replicationとrecovery情報を扱うのに異なるpolicyをFT architectureは扱う。

FT profileの4つのmetamodel
Fault Tolerant Core:Basic concept
Fault Detection:障害の検出。
Object Group Properties:一貫性のチェック。
Replication Styles:レプリケーションのスタイル。

「12.1.1 Core Package for FT Architectures」は、解決策の例を挙げています。
以下の原則があります。
・一つの不具合がクリティカルな障害を引き起こさない。
・システマティックに不具合を監視する
・マニュアルでの障害回復あり。
・Globalで冗長な監視
・Nodeごとの監視あり。
・外部タイマ参照。
FaultToleranceDomain:ServerObjectGroupとReplicasに適用されるデフォルトのpolicy。エラー検出に適用。
ServerObjectGroup
ObjectReplica
- LoggableState
- ReplicaState
- FaultToleranceDomain
FaultDetectorDeploymentPolicy
• StaticallyDeployedFaultDetectors
• InfrastructureCreatedFaultDetectors
• ApplicationCreatedFaultDetectors


12.2 FT Group Properties
MembershipStyle
ConsistencyStyle
- ApplicationControlledConsistency:
- InfrastructureControlledConsistency:
FaultMonitoringStyle
• PullMonitoringStyle
• PushMonitoringStyle
- FaultMonitoringGranularity
- IndividualMemberMonitoring:
- LocationMonitoring:
- LocationAndTypeMonitoring:


12.3 FT Replication Styles
TransientStateReplicationStyle
PersistentStateReplicationStyle
PassiveReplicationStyle
• WarmPassiveReplicationStyle
• ColdPassiveReplicationStyle
ActiveReplicaStyle
• ActiveReplicationStyle
• ActiveWithVotingReplicationStyle

12.4 FT Architectures Profile
FT Architecutreのプロファイルを示しています。4つのコンセプトで表されます。
• the FT policies for the domains (FTFaultToleranceDomain),
• the identification of groups (FTServerObjectGroup),
• the state to be considered in state full replicas (FTLoggableState, and FTHasReplicationState), and
• the replicas styles (FTReplicationStyle and subclasses).
FTFaultTolerance, FTServerObjectGroup:Classifier
FTInitialReplicationStyle, FTServerObjectGroup, FTLoggingState:Class
ReplicationState:Associate

タグ:OCRES
nice!(0)  コメント(0)  トラックバック(0) 
共通テーマ:資格・学び

nice! 0

コメント 0

コメントを書く

お名前:[必須]
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

トラックバック 0