ストラタジーナム メニュー

2010年5月20日木曜日

アーキテクチャー:メタモデルのすすめ ④

要件分析・概念設計の日本固有の現象

創造性の軽視

前回は上流設計の重要性を書きましたが、仕事柄、筆者は開発プロジェクトに関与する事が度々ありますが、最近はつくづく、 その違いを考えさせられます。
最近は日本でもUMLの使用率がかなり上がって来ていますが、大半が実装設計以降での下流工程での使用が中心的で す。

最近はオフショア開発の条件として要件仕様をUMLで書く事が条件になるケースも多いのですが、現地のエンジニアからは、日本の UMLは要件を本当に分析したのか?とか、分析した形跡がまったく見あたらない、と言う意見を聞きます。
「要件仕様をUMLで書いてくれ」と言う リクエストは、国際的には「要件をオブジェクト指向分析設計してくれ」とほぼ同義語ですが、日本人は文字通り、単に表記法としてUMLで書く、と言う意味 で捉えられてる形跡があります。

巷間、日本の携帯電話がなぜ海外で売れないかが一時話題になりましたが、多くの人は、実装技術ではなく要 件分析等の上流工程の品質の問題を指摘していました。
本来、要件設計や概念設計は製品やサービスの価値を決める最もクリエイティブなフェーズであ り、モデリング技術も本来そのために発展して来たものですが、全体に日本のエンジニアは実装設計には熱心ですが、上流工程にモデリングを持ち込む事が苦手 なようです。

アーキテクチャーも同様な傾向が見られ、上流工程のアーキテクチャーよりも実装のアーキテクチャーにのみ関心が集中する傾向 があります。

2010年5月3日月曜日

アーキテクチャー:メタモデルのすすめ ③

前回、筆者が80年代にアメリカにいた頃の話を書きましたが、その当時は、たまに日本に帰ってくると、時間を見つけては日本の港町に旅行に行きました。
 羽田空港からそのときの気分のまま適当に切符を買い、着いた地方空港でレンタカーを借りて、気の向くままドライブしましたが、どういう訳かよく海の方、港 の方へ足が向きました。
そんなある日の事、筆者は、半日のドライブの後たどり着いた小さな漁港に面した居酒屋兼旅館と言った風情の店が気に入り、 ふらりと暖簾をくぐりました。
海の上に大きく赤く腫れぼったい天空の目のような満月が上り、そこは井伏鱒二氏の描くような浪漫的な夕暮れの港町でした。
こんな町で暮らす事が出来たら、どんなに素晴らしい人生だらうか、と若かった筆者はこの静かな美しい港町の生活を想像しながら宿を請うと、奥からごく若い 愛想の良い女将さんが宿帳を持って現れました。
女将さんは、筆者のペン先を見ながら、筆者が「神奈川県」とか「横浜市」と言った当時の住所を書いていくたびに、「はぁ〜」と深いため息をつき、「○○ 区」とか「××町」と進み、所番地あたりを書くあたりになると彼女の感嘆は最高潮に達しました。
彼女の不思議な反応が気になり、筆者は書く手を止めて顔を上げて彼女の顔を見ました。
女将さんは、「昔住んでいた町のすぐそばの所番地だったので、懐かしさのあまり声を上げて仕舞いました」、と訳を話し非礼を詫びました。
彼女は数 年前にこの港町にお嫁に来て、以来一度も横浜には帰っていなかったそうです。
そして、時たま何の目的も持たずふらりと風のようにやって来て、また 風のように去って行く旅の人が現れるが、心底羨ましいと語りました。

人間は、お互いに、自分のないものを羨むもののようです。

上流行程の重要性とその限界

ソフトウェア工学によると、ソフトウェアの品質に最も影響を与えるのは設計フェーズの品質であり、その設計 に決定的な影響力を持つのが要件フェーズです。
オブジェクト指向分析設計も歴史をひも解くと、元々は要件の分析と概念設計の為にモデリング言語が 開発されました。
従って、UMLは本来要件フェーズで最も活用されるべきツールです。
しかしながら、日本での使い方は圧倒的に実装フェー ズで実装設計のツールとしてのみ使われる事が多いようです。
本来、要件を記述するための言語であったUMLがむしろ実装設計にのみ用いられる状況 は、恐らく日本固有の現象のようです。

これは、実装のアーキテクチャーにのみ興味があり、上流部分(ドメイン側)のアーキテクチャーに無 関心な現況とも一致する現象です。

全体に東アジア圏の国々(日本、韓国、中国等)は、実装技術に強い関心を示す反面、ドメイン側に対する 興味は非情に薄いと言われていますが(興味が薄いのではなく、アーキテクチャーやモデリング技術を上流行程に持ち込む発想が薄いだけだと思いますが)、日 本はその傾向が顕著なようです。
理由はともあれ、日本は結果的に上流行程のアウトプット品質が非常に悪いと言う定評を得つつあるのは残念です。
特 徴的なのは、UMLを使わないから悪いのではなく、UMLを用い て書いた要件仕様でも、分析を行なった形跡がなく、単なる表記法としてのみ用いられていて品質の向上が見られないと言うのが平均的な現況の ようです。

昨今のこの状況に対し、日本でも要求フェーズの品質を高める事が脚光を浴び始めて来ました。
しかしながら、水をさすよ うですが、要求フェーズの品質向上だけでは、大した改善は期待出来ない、と言うのが歴史的事実です。

2010年4月29日木曜日

アーキテクチャー:メタモデルのすすめ ②

前回の続きです。

デジャヴ

知人から聞いた携帯電話のソフトウェア開発の現場の話です。
過去の仕様変更の嵐と度重なるスパゲッティ・プログラミン グ、そして一貫性のないパッチワークの積み重ねの結果、もはやソフトウェアが時限爆弾化してしまい、下手に中に手を加えると大爆発を起こす恐れがあり、今 では、出来るだけそ~っとしておき、何か環境が変わると中ではなく外側にソフトウェアをかぶせるようにコーディングし、その場を凌ぐような事態が常態化し てしまったそうです。
彼曰く、日本の携帯はガラパゴス的な仕様の為に死ぬのではなく、ソフトウェア開発の行き止まりによって滅ぶ、ー つまり外敵が来なくても環境変化だけで死ぬ運命にある、と言切っています。
これほど大袈裟な話ではなくても、日本のソフトウェア開発現場ではしば しば聞く話です。
果たして、これは日本固有の話でしょうか?
ー 決してそうではありません。筆者も若い頃ソフトウェア開発現場にいたのですが、アメリカでもフランスでも同じような光景を見た、と断言出来ます。

東海岸

1980年代、筆者はある北米にある通信制御装置(ルーター)の開発部門におりましたが、状況は似たようなものでした。
度 重なる要求の追加、仕様変更の嵐で、コードはどんどん荒れて行きました。
当時勤務していた会社は既にネットワーク・アーキテクチャを標榜しており ましたが、それが事情をさらに悪化させていました。
と言うのも、当時のソフトウェア・アーキテクチャの技術が未熟な上に、市場は非アーキテク チャーの古いプロトコルが大勢を占めており、その非効率なコードがメモリー上に混在し、なおかつ当時の貧弱なプロセッサ・パワーを独占しておりました。
そ の結果、コードの品質が機能の追加更新に耐えられず、頻繁に新しい版を起こし、要求仕様から始めて新しく作り直していました。
(古い版は、最小限 のバグ・フィックスに留め、そ〜っと枯れ死ぬのを待っていました。)
良く誤解されるのですが、このコードの荒れ方は、必ずしも開発規模や機能の数 に比例しません。
通信制御装置よりもさらに膨大な変更の嵐を被っているメインフレーム上のコードよりも、ハードウェア制約の厳しい(つまりハード ウェア資源の貧弱な)通信制御装置上の小さなソフトウェアの方が、早く行き詰まってしまうのです。
メインフレーム上の通信ソフトがたった1回しか 版を変えてない間に(つまり、一回しか要求仕様からの作り直しをしていないのに)、通信制御装置は4回以上版を変えていて、メインフレーム系のエンジニア から怪訝な面持ちで質問された事が度々ありました。(彼らから見ると、たいした機能追加もしてないのに何故そんなに頻繁に版を改めるんだ?と言う気持ち だったでしょう。)

昨今、日本の携帯電話はガラパゴスと呼ばれ揶揄されておりますが、日夜頑張っておられる現場のプログラマーの方々には 同情いたします。
おそらく限られたハードウェア環境が、状況をさらに悪化させていると思います。
適切な方法論がないとコード品質が落ちる のは、プログラマーの能力の問題ではなく、文化国籍の問題でもなく、いわば自然現象なのです。

2010年4月27日火曜日

アーキテクチャー:メタモデルのすすめ ①

先日、学生時代の友人と一緒に高尾山へ行ってきました。
下山後、蕎麦屋で雑談をしているうちに、話題が筆者も多少関与しているグローバル・ス タンダードの話になってゆきました。
彼は、IT部門にいた事はないのですが、ユーザー部門、経営企画部門にいた事もあって、ITにまったく無縁と 言う わけではなく、標準化団体としてOMGの名前だけは聞いた事があったようです。

旧知の気楽さからか、彼はぽんぽんと非常に基本的な 事を盛 んに聞いてきました。
筆者が、「OMGはおもにアーキテクチャーを扱う団体で、最近では会員はITメーカーよりもユーザー企業の方が多 い。」と言 うと、彼は怪訝な顔をして「メーカーのエンジニアがOMGに参加するのは分かるが、ユーザー企業は何のために参加しているのか?」と言う素朴な疑問をぶつ けてきました。
彼にとっては単純な質問だったのかも知れませんが、筆者にとっては、この質問は、ある意味、日本のIT産業を象徴しているように 感 じて少しぎょっとしました。
と言うもの、OMGの参加状況において日本だけ特異なパターンを示す一つの原因に出くわした気がしたからです。
OMG は、欧米を中心に世 界のおもだった企業、組織が参加しており、先に述べた通り、ITベンダーよりもユーザー組織の方が多いのですが、日本だけは面白いことにベンダーが圧倒的 で、ユーザー企業が殆ど参加していません。

従って、世界のユーザー 企業が何故アーキテクチャーの標準化団体に参加するのかを彼だけに説明するよりも、ネットに掲載する方が多少とも世のため人のためになるのではないかと思 い、久しぶりにこのブログを立ち上げました。
(彼にも、このブログを読むよう指示しました。)




 

昨今のアーキテクト事情

90年代半ば頃より前は、ユーザー企業にアーキテクトを置く事は殆どなかったのですが、最近ではある程度のIT規模を持つ欧米の企業の殆どは、アーキテク ト のグループを内部に置いており、かつ中心的な役割を演じるようになってきました。
名称や社内の位置づけは様々ですが(CIOの直下が多いよう です)、エンタープライズ・アーキテクチャーを扱ったり社内標準を扱ったり、場合によってはBPM/SOAを扱う部署と同居したしております。
OMG の中心的な活動に参画するのも、こう言ったアーキテクト達です。

メーカーのアーキテクトとユー ザー企業のアーキテクトの観点はちょっと違いますが、友人の素朴で根本的な疑問である「何故、ユーザー企業が高い金を出してアーキテクトを雇い、なおかつ OMGの ような外部団体の活動までさせているのか?(この不景気なご時世に)」を次回から考えて行きたいと思います。



2009年2月9日月曜日

OCRESブログ 第19回 データ中心 出版ー購読モデルについて

昨年末、茨城県の日立市にリアルタイム系ソフトウェア工学の講習会に講師として行った際、現地の方のご自宅に招待されると言う事がありました。

訪問したお宅は、山の中の山荘と言った風で、床も柱も調度品もすべてが木製で、いかにも趣味人的なお住まいで、筆者の住む都心のマンションとはすべてが正反対の趣でした。

筆者もかつては郊外に暮らした事もあったのですが、最近の都心回帰の波に流されて現在の住処と成りましたが、元来が自然派ですので都会暮らしもだんだん疲れて来ており、この山荘風のご自宅を拝見し、筆者もそぞろどこかへ自然回帰したくなって来ました。
真っ先にあたったのが、八ヶ岳近辺の高原ですが、時刻表を調べると東京まで片道4時間ぐらいかかり、往復8時間の通勤は極めて非現実的なので諦めました。

世界的に見ても、知識集約型産業は、大都会ではなく歴史的な中小都市、観光都市の近郊に発達していますが、これは単に効率だけが産業の鍵ではない事を暗示しているようです。

筆者の転地先ですが、今は鎌倉とか逗子・葉山辺りを検討しております。

データ中心・出版ー購読モデル について

OMGの標準の一つに DDS(Data Distribution Service)があります。
この仕様は、元々は軍事アプリケーション、特に分散ハード・リアルタイム系システムのために作られたものですが、面白い事に当初予想された分野を遥かに超えて普及してゆき、民需分野でも広く使われるようになって来ました。

標準仕様も商品と同じく、これは普及すると思ったものが案外流行らなかったり、ごく一部での使用のみを想定していたのに、予想以上に受け入れられたりするものですが、このDDSは後者の代表例として挙げられるでしょう。
この標準が広く受け入れられた最大の理由として、アーキテクチャの基本として「データ中心・出版ー購読モデル」を採用した事が挙げられます。
このモデルは、ご存知の通りOCRESにも出題されています(概念モデルが出題の対象。実装モデルは出題の範囲外です)。
このモデルは、非常に解りやすく、且つ緻密に出来ており、アーキテクチャとは何か?を考える上でも非常に役立ちます。

このたび、OMGのジョン・シーゲル博士(技術移転担当VP)がこのモデルとともに現在予定されているDDSの拡張計画について書き下ろしましたので、次回の組み込みプレスに投稿いたしました。( 14号と15号の2回)
ご興味をお持ちの方は、ぜひご参照ください。


2008年11月2日日曜日

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

「しなの」の語源 2

以前、「信濃(しなの)」の語源の話をしていて、途中で終わってしまった回がありましたが、本日はその続きを書きます。

前回、「しな」と言う語が付く地名は全国的に散在し、その多くは河岸段丘の地形が見られると言う話をしました。
(このブログを書いた後にもまた、友人のS君から、「東京の品川の語源も河岸段丘じゃないか?」と言う指摘を受けました。品川は目黒川の下流域の名称ですが、周囲の開発の関係で、元の地形が確認しづらくなっておりますが、その可能性は非常に高いと思います。)

ところが、不思議なことに、「しな」地名が集中する信濃では、河岸段丘と「しな」地名はほとんど一致しません。
ここで注意しなければならないのは、その地名がいつ命名されたか、という点で、例えば、「望月の駒」で有名な望月町のそばに、かつて浅科村と言う村がありましたが、この村の周囲に河岸段丘が見られないと言っても、語源的な議論には役立ちません。
というのも、浅科村は、浅間山と蓼科山の中間にあることから昭和30年代に命名された新地名であって、少なくとも千年以上前から存在する他の「しな」地名とは、区別する必要があります。

そこで、文献などで可能な限り古くから存在する事が確実な、「しな」地名を洗い出しましょう。
次をクリックすると、長野県内で、少なくとも平安時代から存在が明らかな「しな」地名を示した地図がポップアップします。(延喜式や三代実録などからピックアップ)

「しな」地名地図

図中で青色で示した地名が、古代から存在する事が確実な「しな」地名で、長野県内でも特定の東西に広がる帯状の地域に集中している事が分かります。
実は、この帯状の地域には、この図で示した「しな」地名以外にもたくさん「しな」が付く地名や神社が集中して存在するのですが、現存の文献では時代が確認できないため割愛しています。

さて、これらの地域に共通するものは何でしょうか?
好奇心に駆られて、今から十年ほど前に、この辺りを旅行がてら調べた事があります。

(次回に、続く・・・)

リアルタイムUMLの応用講座
このコースは、前回紹介した「UML2を使用したリアルタイム・ソフトウェア設計講座の後続篇、上級版になります。



応用編のため、オブジェクト指向やUMLの基本的な使い方が前提知識として要求されます。
既に、UML設計の経験はあるが、UMLの使用法をより向上させたい設計者や、UML使用上の実践的な技法を学びたい人が対象になります。

リアルタイムUMLの応用講座 アジェンダ

システム要件の分析と定式化

ー シナリオとユースケース
ー システムスコープと、直接的・間接的アクター
ー アクター・システム間の相互作用を図的にモデリング

システムとソフトウェアの要件を定義

ー システム・ユースケース・モデル
ー システム相互作用モデル
ー システム・スコープ・モデル
ー システム動的モデル
ー ソフトウェア・ユースケース・モデル

巨大システムの設計

ー サブシステム・モデルの開発
ー パッケージとコンポーネント
ー 現実世界とのインタフェース; デバイスとソフトウェア間の相互作用

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

ー 理念的な環境下でのオブジェクトの関係、コミュニケーションと制御

仕様モデルの開発

ー 理念的モデルと実装モデルのミスマッチ
ー コンポジット構造、ポートと提供/要求インタフェース

並列処理システムとタスク・ベースの設計

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

実装モデル ー タスク・ベースの設計

ー 仕様モデルを実装モデルへマッピング
ー タスク間コミュニケーションの課題

実装モデル ー 実践的なシーケンシャル・モデル

ー シーケンシャルなコードで、オブジェクトの振舞の集まりを制御 ー 制御オブジェクト
ー アクティビティ図を用いたアルゴリズム(プロセス)の指定方法

コードの問題

ー 論理的/物理的モデル
ー ソフトウェア ー 構築と成果物
ー ソフトウェアの構造化とパッケージング
ー モデルの実装

分散/多重コンピュータのシステム

ー リアルタイムシステムのための多重コンピュータ・アーキテクチャ
ー ソフトウェアをハードウェアへマッピングする上での基準
ー 実践的な設計技法

事例研究

ー 統合アプリケーションの設計


2008年10月22日水曜日

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

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

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


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

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

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


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

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



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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

中規模システムの開発

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

大規模システムの開発

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

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

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

ユースケース分析

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

事例研究

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