解答例

• ツールの画面例
• ツールのデータ [XML]
• うちのポリシー [TXT]

• 解答例 [TXT]

• 要求を1個追加 「他の場所での取引による残高の変化を反映させられる．」
  Detailのタブにもメモしてあるが，別にこのシステムのみで 買い物をしてるわけじゃないので，他で行った買い物による残高の変化を カード会社側から更新したいところだが， パーミッションのレベルではそれが可能となっている． (そういうロジックが組まれているかどうかは別)
• 脅威は一応，4個思いついた． 一応，書いてある順番に「重症」と思っている．
  脅威発生の根源は注文内容に相当するファイルが任意指定(*) であることに依存する．
• 私の妥協法としては，この「ファイルの任意指定」 に関する自由度を諦めた．
  ポリシー上は order.txt という一意のファイルにしか注文を保存できなくした． ま，妥当な線じゃないかな．

解説や考察 (順不同)

• ツールを使いながら書いてから，使わない解答例を作ったから楽だったけど， 逆だと結構めげるな．
• ともあれツールは要求の意味的な依存関係を無視しているので， ちょっと解答がウソっぽいところがある． 例えば 手作業の解答例では， 断念(妥協)してるのは注文内容を書き込む場所の任意性のみであり， これが確定すれば注文内容を読むだけの要求は特に妥協もなく充足できる．
  しかし，ツールでは，最初に読む方も任意のファイルを読めるパーミッション と結びつけてしまったので，断念扱い(黄色)になってしまっている．
• ツールで機械的に割り切れる部分を判別し， あとは内容を考えて手作業で修正するのがベターだろう． (もしくはツールをもちっと賢くするとか・・・)

• この問題は以下の二点が脅威を発生させる原因となりうるが， 後者はあまり効いてこない．
  1. 注文内容を記録するファイルが「適当(任意)」であること．
  2. カード会社対応のコードとショップ対応のコードが同じ場所(URL) においてあること．
• 演習中に口頭で補足したが， 各コードには 問題文に提示されている以外の「隠しパーミッション」 は含まれないものと考えてよい． これは，パーミッションの有無自体はソースコードもしくはクラスファイルの 解析を行えば判明してしまうためである．
• 現状では注文内容を構造を問題に明記していないので， カード会社にも何を買ったか(ハヅカシイものとか)の情報が漏洩してしまう．
  この点は何せ注文内容データが分離されていないので， どーしようもない．