OCRESブログ 第17回 ソフトウェア設計のトレーニング法 3

以前このブログにも登場したことのある友人のS君が、座間から筆者を訪ねてやって来ました。
S君はかなり博識で話題豊富な人ですが、今回は「裁判員制度」で盛り上がりました。

そもそも裁判の判決を下す際に専門の裁判官以外に外部の人間を入れて判断させる制度は、先進国ではかなり幅広く受け入れられている制度で、国によって大きく２つの系統に分けることが可能です。


一つは陪審員制度で、一般人が一個の裁判に関し有罪無罪だけを判断するもので、アメリカやイギリスで取り入れられており（英米法）、もう一つは参審員制度と呼ばれ、一定の任期間に複数の裁判に関し裁判官とともに、有罪無罪だけでなく量刑も判断するもので、こちらは、任期内の複数の裁判を量刑も含めて担当し、いわばセミプロ的な人が、合議制の裁判に参加する形で、フランスやドイツなどで採用されています（大陸法系）。

日本の裁判員制度は、この２つの折衷案的なもので、一般人が参加するという点では陪審員制度と似ており、有罪無罪だけではなく量刑も判断するという点では参審員制に似ています。

従って従来、司法に民主的コントロールを取り入れることに遅れていた日本が、ここでは、一般人に有罪無罪だけでなく量刑も判断させるという極めて先進的な制度を取り入れることになります。


民主主義国家として古代より最も名高いギリシャでは、政治だけでなく、裁判も極めて民主的にやっており、なんと数百人の自由民が多数決で判決を下していたそうです。

そして、その制度の悪例（？）として名高いソクラテスのケースでは、「若者のをそそのかした」と言う罪で訴えられた際、その数百人の裁判官に対して悪態をつき喧嘩を売ってしまって、怒り狂った裁判官たちから死刑の判決を得てしまったそうです。
（その当時の例から見ても、ひたすら恭順の姿勢を見せていたら無罪放免になったかもしれず、とても死刑になるような罪ではありませんでした。）
また、その後も、ソクラテス自身、いくらでも逃げようとしたら簡単に逃げきれるにも関わらず、友人の忠告も聞かず、毒杯を仰いで死んでしまいます。有名な「悪法もまた法なり」という言葉はこの時のセリフと伝えられています。（ソクラテスはかなり意地っ張りな性格の奴だったと、筆者は睨んでおります。）

このギリシャ時代の制度から比べると、さすがに現代の制度はかなり洗練されてきています。

陪審員制度の根底にはカント流の哲学があると言われ、人間の知性のうち、悟性（物事そのものを把握する能力）は（他の知的能力、理性とか判断力とか言ったものに比べ）どんな人にもかなり平等に割り当てられていると信じられています。

また統計的に見ても、陪審員が裁判官よりも感情的あるいは非論理的判断をするとは証明されておらず、むしろ逆にアメリカなどでは裁判官よりも陪審員制度の方が信頼されています。
（陪審員の方がより慎重な判断をする傾向があり、裁判官の方が、検事や時の権力側に近い判断を下す傾向がある、と言われています。）

さて、日本の裁判員制度ですが、歴史的試行錯誤や哲学的バックグラウンドが全く無い代わりに、運用によっては司法制度に極めて強力な民主的コントロールが提供される可能性を秘めています。

しかしながら、S君も筆者も、その「運用によっては」という部分で、その効果に悲観的です。
現在の検察審査会も「運用によっては」かなり民主的なコントロールが可能な制度でありますが、残念ながらそのように「運用」されていません。
裁判員制度も、単なる形骸的なものにならないよう、制度の改善を模索しながら、前に進んで行くしかないでしょう。


UML2を使用したリアルタイム・ソフトウェア設計講座

この講座も、前回ご紹介した「SysMLを使ったシステム工学講座」と同様、設計演習を中心としたコースです。
ジム・クーリング博士によると、設計講座においていわゆる設計ツールを使用して演習すると、受講者は皆ツールの使い方の方に注意が行ってしまい、肝心の設計の方が疎かになる傾向があるため、彼の開発したトレーニング・コースはすべてツールを使わずに設計図（モデル図）は手で描く事になっています。

注意すべき点として、初学者は往々にして、設計ツールが使えると言うことと、設計が出来ると言うことを混同してしまう傾向があります。

受講者は、様々なソフトウェアの開発ツールの使用経験があると思いますが、ことUMLツールに関して言えば、どのツールも（もちろん機能の過不足はありますが）深いレベルで似通っており、学ぶよりも慣れの方が有効であり、短い演習時間をツールに慣れるために使うのは、時間の無駄と言えます。

さて、このコースの中身の解説は、「組み込みプレス」の次の号に投稿しましたので、そちらを参照頂くとして、ここでは、コースのアジェンダを紹介いたします。

UML2を使用したリアルタイム・ソフトウェア設計講座 アジェンダ

リアルタイム・システム設計入門

ー リアルタイム・システムの概要
ー インクリメンタル設計プロセス

ソフトウェア・マシン ー 基礎

ー モジュラー構造化の基礎と実践
ー プログラム設計における図法のテクニック ー UMLアクティビティ図

オブジェクト指向設計の概念

ー オブジェクトのコラボレーションの集まりとしての設計システム
ー クラス、オブジェクトとそれらの特徴
ー 設計・構築の鍵となる課題： ソフトウェア・テンプレート、カプセル化、インタフェース、情報隠蔽、継承と集約

クラスとオブジェクトのモデリングの基本

ー 設計テンプレート、 カプセル化、インタフェース、情報隠蔽
ー クラス・オブジェクトの汎化特化間系： 継承

動的振る舞いのモデリング

ー システムとオブジェクトの動きを定義するための状態図
ー UMLステート・マシン図の概念、文法、セマンティクス

理念的なオブジェクト・モデルの開発

ー 理想環境下における、オブジェクトの関係、コミュニケーションおよび制御
ー シナリオ、シーケンス図とコミュニケーション図
ー 責務に基づく設計テクニック
ー 実世界とのインタフェース

実践的な逐次（プロシージャ型）オブジェクト・モデル

ー 逐次的コードで、オブジェクト群の振る舞いを制御： コーディネータ・オブジェクト
ー アクティビティ図を用いて、アルゴリズム（もしくはプロセス的な）操作を指定

小型システムのための仕様モデルの開発

ー 仕様モデルの役割
ー 並列処理、非並列処理の構造 ー アクティブ・オブジェクトとパッシブ・オブジェクト
ー オブジェクト構造の仕様化 ー フラットなオブジェクト構造

並列処理システムとタスクに基づく設計

ー 抽象的なソフトウェア設計に伴う問題
ー マルチタスキング設計の基本

小型システムのための実装（タスキング）モデルの開発

ー 仕様モデルからタスキング・モデルへのマッピング

中規模システムの開発

ー コンポジット構造、ポート、インタフェース入門
ー コンポジット構造のための仕様モデルの生成
ー 実装（タスキング）モデルの仕様化

大規模システムの開発

ー 鍵となる構成ブロック ー パッケージとコンポーネント
ー サブシステム構造の設計
ー 実装モデリング

多重コンピュータ・システム

ー リアルタイム・システムのための多重コンピュータ構造
ー ソフトウェアをハードウェアにマッピングするための基準
ー 実践的な設計テクニック

ユースケース分析

ー 用件を構成し表現するためのユースケース
ー シナリオとユースケース
ー システム・スコープと直接的、間接的なアクター
ー アクターとシステム間のインタフェースを図的にモデリング

事例研究

ー コンピュータ制御の測定器の組み込みソフトウェアを題材

OCRESブログ 第16回 ソフトウェア設計のトレーニング法 2

先日、久しぶりに一橋の学士会館に行って来ました。
昔、友人の結婚式で何度か足を運んだ事がありましたが、ここしばらくは全く縁がなく、場所をすっかり忘れてしまっており、地図なしにはたどり着けないほどになっていました。
そして、何気なく会館の関係者の方とお話ししている中で、この地が、漱石ゆかりの場所であった事を初めて知りました。

現在、筆者の自宅がある町から、長い坂道を下って行った所に、明治の文豪、夏目漱石の生家跡があります。そして、ここに越して来たばかりの頃は、散歩がてらに、漱石が歩いたであろう道筋をたどったりしていました。（この近辺は、江戸末期の道筋が結構残っています。）
その結果、筆者も、漱石を通して江戸や昔の東京の歴史に興味が涌いてくるようになりました。

漱石は、明治維新の頃、今の早稲田大学のすぐそばで生まれ、当時出来たばかりの東京大学予備門（後の旧制一高）へ入学し、帝大（今の東京大学）へ進んだ事は有名ですが、その当時、予備門や帝大がどこにあったかは、あまり知られていません。
筆者も、漠然と今の本郷にあったのだろうと言う位にしか考えていませんでしたが、実は、漱石が予備門の学生だった頃の東大は、今の学士会館の場所あたりにあったそうです。
この近辺から神保町、駿河台にかけて大学が多く、神田に古本屋が集まり日本一の学生街が形成されたのも、それがきっかけだったそうです。

SysMLを使ったシステム工学 講座
前回に引き続き、ジム・クーリング博士のトレーニングコースを見て行きたいと思います。
本日は、「SysMLを使ったシステム工学 講座」を、ご紹介します。

システム工学／要求工学の重要性

現在のシステム設計において、要件フェーズはますます重要性となって来ており、昨今では要件を分析しまとめるための工学、要求工学と呼ばれる分野が急速に発達してきました。
この要件フェーズは、一つの方法論、一つの視点からだけではなく、複数の方法論、視点を組み合わせて用いる事が重要である事が知られて来ています。
ジム・クーリング博士の本には、要件分析と仕様化の手法として、「ビューポイント法」、「ユースケース法」、「プロトタイピング法】等が取り上げられていますが、これらに加えて、ここ数年の間に急激に普及して来た手法があり、それがSysMLです。
このSysMLの普及速度は、かつてのUMLの普及速度を遥かに凌駕しており、本格的な登場からまだ３〜４年ほどしか経っていないのにも関わらず、システム設計の事実上の主流になっており、急激にデファクト・スタンダード化して来ています。

SysMLとは ?

読者は、UMLが第２版（UML2.0)になって、UMLが単にソフトウェアの表記法ではなく、極めて強力な汎用モデリング言語になった事はご存知だと思います。

実は、SysMLは、UMLの一種であり（サブセット）、特に「システム」を記述するために（プロファイリング機能を用いて）拡張されたものなのです。

システム・エンジニアリングあるいはシステム工学と言う分野は、コンピュータの誕生以前から存在し、飛行機や自動車と言ったシステム製品を、個々の部品や技術要素の観点からではなく、システム全体としての動きや品質にフォーカスを当てています。
勿論、この分野でも従来から様々な表記上の工夫はなされていましたが、不統一で一貫性に問題があり（メタモデル化されていない）、また分野ごとにバラバラでした（標準化されていなかった）。
UML2.0の登場とともに、システム・エンジニアたちは、待ってましたとばかりに、SysMLを標準化し、本格的に使い始めました。（既存のUMLツールが使用できるのも、メリットの一つです。）

ソフトウェア工学とシステム工学

ソフトウェアを設計する上でソフトウェア工学（もしくはソフトウェア・エンジニアリング）の知識が有益である事は論を待ちませんが、システム工学（システム・エンジニアリング）を学ぶ事は、ある意味もっと重要な事なのです。（全体と技術要素の関係）

下に、本コースのアウトラインをまとめました。

コース概要

システム工学入門
ー システム工学とは？
ー システム工学の概念
ー 「揺りかごから墓場まで」のための工学
ー System V-model

UML2.0とSysMLの違い
ー UML2.0のサブセットとしてのSysML
ー UML2.0の拡張

要求分析
ー ”従来の方法” 対 ”ビューポイント法”
ー 要件図
☆ 従来の要件をモデリング
ー ユースケース・モデル
☆ ユースケース・レベル
☆ ゴール指向ユースケース
☆ ユースケース記述
ー システム・コンテキスト・モデル
ー システム・モード・モデル

システム構造の定義
ー パッケージ図
ー ブロック定義図
☆ システムの論理構造の定義
ー 内部ブロック図
☆ 内部アーキテクチャの定義
☆ 構造化クラス（UML2.0)との比較
ー ポートとフロー
☆ 標準ポート
☆ アトミック・フロー・ポートと項目フロー
☆ ノンーアトミック・フロー・ポートとフロー仕様
☆ インタフェース

システム動的モデリング
ー シーケンス図
ー アクティビティ図
ー ステート図

システムのパフォーマンス分析
— 制約のモデリング
☆ パラメトリック・モデル
☆ システム要素に数学モデルを割り当てる

標準
ー IEEE-1471-2000
— ARP-4754

システム工学のためのPragma+プロセス
ー すべてを統合する