伊藤 潔

本稿では, 複数種類の担当者が情報を共有して作業をすすめる協調作業ドメインを分析し, そのドメインモデルを提案する. このドメインを記述する視点は, 扱う情報の項目, 情報を参照・更新する作業フロー, 作業フローの担当者の3種類ある. これらの各々の視点を詳細記述し, また視点間の関係を明確化するためのダイアグラムや記法を検討した. この結果, 作業者間の関係はERD(Entity Relationship Diagram), 作業毎の作業フローはSFC(Sequential Function Chart), 情報項目と作業フローの関係は表など, 記述する視点や関係に応じたチャートや記法を明らかにした. また, これらの記述を効率的に行うための順序を提案した. 例題として, 医者, 看護婦, 薬剤師, 会計事務などがカルテ情報を共有する, 病院の診察業務ドメインを取り上げた. 記述する視点に応じたダイアグラムや記法を採用することで, 効率的なドメインモデル記述が可能となった. また, 協調作業という抽象的なドメインに固有で, かつこれに属する複数のより具体的なドメインに共通する記述順序, すなわち, プロセスモデルを抽出することができた.

本稿ではドメインモデルに基づいたシステム開発支援法と, これを用いた開発支援ナビゲータを提案する. 対象ドメインとして定型的な帳票で取引きを行う販売管理ドメインに注目する. このドメインモデルを構成するテーブル群 (帳票に対応) と問合せ仕様 (帳票処理に対応) をシステム開発に再利用するため, 対象業務の語彙, 帳票, 帳票処理をドメインモデルのそれと比較する. 単純な語彙変換で利用可能なテーブル群や問合せ仕様はシステム開発に再利用する. ナビゲータはこの開発支援プロセスを実施する. システム開発担当者にドメインモデルの選択や語彙の列挙・比較を指示し, ドメインモデルの再利用可能な部分と対象業務向けに開発する部分の切分けを示唆する. これにより効率的なシステム開発を推進する.

ドメイン分析/モデリング技法を用いたリアルタイムシステムのドメインモデルを紹介する。リアルタイムシステムは処理すべき機能の仕様化や設計だけでなく、末端装置からの処理要求に対する応答時間の制約の仕様化や、時間制限を検証し、あるいは性能改善を行なう設計プロセスが必要である。一方、ドメイン分析/モデリングの技法を使って、似た性質を持つシステムのグループ(ドメイン)に独特な仕様モデル、解のモデルを開発し、これを再利用することで、実際のシステム開発の生産性を向上できる。著者らが提案しているTriadic Domain Model(TDM)を適用し、ドメイン固有のシステム開発プロセスを明かにすることにより、システムの生産性は更に向上できる。本稿では、リアルタイムシステムで用いられる技術であるデータベース、並列処理、分散処理を実装する際のプロセスから、リアルタイムシステムのドメインの設計には機能設計と性能設計の間を行き来する「行きつ戻りつプロセス」が特徴的であることを論じた。

パイプライン計算機における性能評価・性能改善手法PIPEDIETSを提案する。パイプラインの論理を与えられた時に、遅延時間のボトルネックを判定し、セルの移動やパイプラインステージの増減などの性能改善を実施する際のアルゴリズムを考案した。セル移動した場合の機能の等価性を保証するため、まとめて移動する必要のあるセルを判定する。セル移動では2種類の手法を考案した。1つは全ステージの遅延時間の状況を把握し、大局的に性能改善を行なう。もう1つは最も著しいボトルネックから順次改善を行なう。これらは対象とするアーキテクチャの論理規模に応じて使い分けるのが好ましい。

本稿では類似したシステム群をより少ない工数で開発するためのドメインモデルの構築法とその利用法について述べる.対象としてセールス業務ドメインを取り上げる.当該ドメインでは,商品,顧客,問屋といったエンティティと,仕入れ,販売のオペレーションが存在する.これらに対応するテーブル仕様と問い合わせ仕様から成るドメインプロダクトモデルを導出するための,語彙の列挙,グループ化,関係付けを行なうドメインプロセスモデルを構成した.これらのセールス業務のドメインモデルは,獲得したプロセスモデルに沿ってテーブル仕様や問い合わせ仕様のモデルに個々のシステム依存の要素を追加・改変することにより,ドメインに含まれるシステムの開発に再利用可能である.

本稿では類似したシステム群をより少ない工数で開発するためのドメインモデルの構築法とその利用法について述べる.対象としてセールス業務ドメインを取り上げる.当該ドメインでは,商品,顧客,問屋といったエンティティと,仕入れ,販売のオペレーションが存在する.これらに対応するテーブル仕様と問い合わせ仕様から成るドメインプロダクトモデルを導出するための,語彙の列挙,グループ化,関係付けを行なうドメインプロセスモデルを構成した.これらのセールス業務のドメインモデルは,獲得したプロセスモデルに沿ってテーブル仕様や問い合わせ仕様のモデルに個々のシステム依存の要素を追加・改変することにより、ドメインに含まれるシステムの開発に再利用可能である.

本稿では、ドメインモデルを獲得する1手法として、複数のドメインモデルの比較分析によるアプローチ(COmparative Approach to Domain Analysis/Modeling: CoADAM)を提案する。CoADAMは、類似した複数のドメインを構成する項目(構成要素、構造、機能、振舞いなど)を列挙・整理・比較することによって、ここのドメインモデルを開発し、これらに共通の項目を抽出し、より抽象的なドメインモデルを獲得する。新たにドメイン分析を行なう場合に、得られた個々のドメインモデル、抽象的なドメインモデル、あるいは別途獲得した既存のドメインモデルとの比較分析を行ない、抽象度の高い項目から演繹したり、既存の項目を流用してドメインモデルの項目を整備する。これにより、新規開発に比べて少ない工数で所望のドメインモデルを開発することができる。本稿では例題として、図書館、レンタカー、列車の座席予約などを「レンタル業務のドメイン」と捉え、比較分析や抽象化を行なった。

リアクティブシステムの麗発環鐘Asdreas（Architecture for the spesification and Design of Reactive System）の目的は、リアクティブシステムの要求分析と主要な基本的な機能の列挙をサポートすることである。リアクティブシステムは、プラントの計測・制御・監橿を目的としたリアルタイムシステムである。Asdreasを構成する際に、現実のリアクティブシステムの間題領域とシステムにまつわるさまざまな要因について、十分に分析を行った。その緒果、リアクティブシステムの要求分析と機能列挙向きのドメインモデル、三群状態遷移モデル（STD Triad）を考案した。Asdreasでは、リアクティブシステムは、制御する側のリアクティブスーパバイザと、制御される側のリアクティブプラントから構成されるものと認識する。これらは、互いに相手のアクションに対してリアリタイムなリアクションを行う。Asdreasの要求分析・設計手法の特徴は次の2点である。A）プラントの挙動をシステムの分析と設計上の間題として明確に認識。B）リアクティブシステムの挙動を、STD Triadの枠組みに基づいて（1）自然状態群、（2）作用状態群、および（3）目標状態群の3つの状態群に類別されたプラントの状態遷移図（PIant STD）として分析。本稿は空調制御リアクティブシステムを事例とする。

三面図が表す三次元物体を求める手段として、単純に各面図の頂点や触分について各面図問で対応をとり、三次元空間上の頂点と稜線から成るワイヤフレームモデルを作成し、それらの稜線で囲まれた領域を面として認識したサーフィスモデルを作成する方法が考えられる。この方法をとると、虚物体要素を舎むサーフィスモデルを作成してしまう場合がある。この虚物体要素を舎むサーフィスモデルから所望の物体を見出すためのこれまでの多くの方法では、試行錯誤的な探索プロセスのアルゴリズムを提案している。我々の方法は新たな探索アルゴリズムではなく、連立の非線形の擬似プール代数等式・不等式を用いた非線形計画法による制約充足問題とみなして解く手法である。そこでは、候補物体要素の真偽を適切に見極めるための真偽決定規則として、物体要素群が多面体を構成するための条件および三面図に合致するための条件を挙げる。それらの条件を非線形項による擬似プール連立式で定式化する。この定式化に基づいて候補物体要素群を連立式として立式する。この連立式の解を基に、多面体を構成し、かつ三面図に合致する物体要素群を求める。三面図に適合する全ての多面体はこの計画問題の制約式を連立して解いたものとなり、常識的と思われる多面体のみの合成は、heuristicsに基づいた目的関数を与えてこの計画問題を解いたものとなる。

三面図が表す三次元物体を求める手段として,単純に各面図の頂点や線分について各面図間で対応をとり,三次元空間上の頂点と稜線から成るワイヤフレームモデルを作成し,それらの稜線で囲まれた領域を面として認識したサーフィスモデルを作成する方法が考えられる.この方法をとると,虚物体要素を含むサーフィスモデルを作成してしまう場合がある.この虚物体要素を含むサーフィスモデルから所望の物体を見出すためのこれまでの多くの方法では,試行錯誤的な探索プロセスのアルゴリズムを提案している.我々の方法は新たな探索アルゴリズムではなく,連立の非線形の擬似ブール代数等式・不等式を用いた非線形計画法による制約充足問題とみなして解く手法である.そこでは,候補物体要素の真偽を適切に見極めるための真偽決定規則として,物体要素群が多面体を構成するための条件および三面図に合致するための条件を挙げる.それらの条件を非線形項による擬似ブール連立式で定式化する.この定式化に基づいて候補物体要素群を連立式として立式する.この連立式の解を基に,多面体を構成し,かつ三面図に合致する物体要素群を求める.三面図に適合する全ての多面体はこの計画問題の制約式を連立して解いたものとなり,常識的と思われる多面体のみの合成は,heuristicsに基づいた目的関数を与えてこの計画問題を解いたものとなる.

同期型待ち行列ネットワークの性能パラメータの測定平均値に対して，定性推論でパラメータチューニングする手法を述べる．この手法に基づいて，ボトルネックサーバを同定しその要因を解明し，択一的に選択可能な定性的な改善プランを提示するエキスパートシステム"Bottleneck Diagnosis Expert System for open Synchronized queueing network:BDES?S"（[SHI9)を開発した．BDES?Sの定性的な改善プランはパラメータ間の増減関係のみを定めるものである．This paper describes Bottleneck Diagnosis Expert System for Synchronized queueing network (BDES-S). On the basis of qualitative reasoning, BDES-S can carry out parameter tuning in order to diagnose and improve bottlenecks of synchronized queueing networks. BDES-S can produce several alternative qualitative improvement plans for one bottleneck server.

待ち行列ネットワークのボトルネックを改善するために，定性推論に基づいて複数の改善プランが得られる．これらの改善プランのうちどのようなタイプの改善プランを選べば改善度合が大きくなるかという改善プランの選択基準について述べる．選択基準には，ボトルネックの改善に要する時間の最小化のための選択基準，および改善プランの周辺への影響量の最小化のための選択基準がある．In order to improve a queueing network bottlenecks, many of improvement plans can be produced by qualitative reasoning. This paper describes the plan choice criteria. The criteria can produce the optimal plan with large improvement effect. There are two criteria, i.e., minimization of time for improving the bottleneck and minimization of influence on the circumfernce.

同期型待ち行列ネットワークの性能パラメータの測定平均値に対して，定性推論と定量推論を相補的に組み合わせてチューニングする手法を述べる．この中で2つのエキスパートシステム，すなわち，ボトルネックサーバを同定しその要因を解明して，択一的に選択可能な定性的な改善プランを提示する"Bottleneck Diagnosis Expert System for open Synchronized queueing network: BDES-S"と，択一的に選択可能な定量的な改善プランを提示する"Bottleneck Improvement Expert System for open Synchronized queueing network: BIES-S"について述べる．BDES-Sの定性的な改善プランはパラメータ間の増減関係のみを定めるものであり，BIES-Sの定量改善プランはパラメータの具体的な増減値を定めるものである．This paper describes Bottleneck Diagnosis Expert System and Bottleneck Improvement Expert System for Synchronized queueing network (BDES-S and BIES-S). BDES-S and BIES-S carry out parameter tuning for performance measurement data, with the combination of qualitative reasoning and quantitative reasoning, in order to diagnose and improve bottlenecks of synchronized queueing networks. BDES can produce several qualitative improvement plans for one bottleneck server. According to one of these qualitative plans, BIES can carry out automatic parameter tuning to remove the bottleneck by quantitative reasoning.

対象システムに悪影響を及ぼすものとその要因を解明し改善する作業は 一般的に手間がかかる.また 対象システムの規模が大きく複雑であれば 改善プランも数多く存在する.さらに ある箇所を修正すると周辺への影響も大きい・このような作業は 通常 専門的な知識と経験を用いて行われている.これらの作業に対してエキスパートシステムを導入すると 評価や改善の効率を高めると期待できる.待ち行列ネットワークの形態にモデル化できるシステムを対象システムとする.また この対象システムには過大な負荷がかかっている すなわち そのモデノレである待ち行列ネットワークは 非定常(過負荷)状態にある あるいはその可能性をもつシステムとする.このような待ち行列ネットワークに悪影響を及ぼすものとして 稼動率や待ち行列長が過大な窓口(ボトノレネック窓口)に着目する・このような窓口の同定その要因の解明 および改善プランの提示を行う"ボトノレネック診断エキスパートシステム(Bottleneck Diagnosis Expert System:BDES)"について考察する。そこで用いられるヒューリスティクな知識は 対象システム内の窓口の接続の形状やパラメータの大小関係により詳細に分類したものであるこれらは Prolog言語の事実や規則を用いてインプリメントされた.

本稿では，待ち行列ネットワークの性能パラメータの測定データを，定性推論，ヒューリスティクス，定量推論の組み合わせでチューニングする"ボトルネック診断エキスパートシステム(Bottleneck Diagnosis Expert System:BDES)"と"ボトルネック改善エキスパートシステム(Bottleneck Improvement Expert System : BIES)"を述べる．BDESは，ネットワーグの部分形状に関する知識と，その部分形状内の性能パラメータ間の制約に関する知識とを踏まえて導かれた定性式をもち，更にこの定性式の適用順序制御に関する知識（ヒューリスティクス）をもつ，BDESは1つのボトルネック窓口の改善プランを出力する．BIESは，この改善プランを入力として，その窓口とこれに影響を受ける全ての性能パラメータの値を定量推論する自動チューニングの知識をもつ．これらは，Prolog言語・を用いてインプリメントされた．This paper describes Bottleneck Diagnosis Expert System (BDES) and Bottleneck Improvement Expert System (BIES). BDES and BIES carry out parameter tuning for performance datas, with the combination of qualitative reasoning, heuristics and quantitative reasoning, in order to remove bottlenecks of queueing networks. The qualitative equations and the control mechanism of their application are built in BDES on the basis of the heuristic knowledges on substructures of networks and on performance parameter constraints. BDES can output several improvement plans for one bottleneck server. With the use of one of these plans, BIES can carry out automatic parameter tuning to remove the bottleneck by quantitative reasoning. BDES and BIES are implemented in Prolog language.

システムの評価は,対象システムの設計や分析とその改善を行なうために必要な評価データを得る目的で行なわれる重要な作業である.この評価作業の重要な目的の1つとして,対象システムに何らかの悪影響を及ぼすものとその要因を解明することが挙げられる.ここでは,待ち行列ネットワークの形態にモデル化できるシステムを対象システムとする.また,モデル化した待ち行列ネットワークの中で,移動率が過大な窓口や過小な窓口を対象システムに悪影響を与えるものとして取り上げる.稼動率が過大な窓口はボトルネックとなる可能性があり,稼動率が過小な窓口は周囲の窓口をボトルネックにしている可能性があるとする.ある窓口のボトルネック状態を解消するためには,その窓口の能力を高めたり,その窓口への到着量を軽減するなどの改善の方策が必要となるが,このような方策で稼動率を下げると,周辺に影響が出て,暗には他の窓口をボトルネックとしてしまう場合もある.このようにシステムの評価に伴う改善作業は必ずしも容易ではない.システムの評価の際には,数学的なモデルを用いた方法や,シミュレーションによる方法,実測による方法などが用いられるが,ここではシミュレーションによる方法を用いる.本稿では,待ち行列ネットワークのシミュレーションモデルとシミュレーション実行後の評価データに対して,ヒューリスティックな知識を用いて,このような窓口の同定,その要...

並行処理ソフトウェアシステムの設計段階に適用されるソフトウェアプロトタイピング手法とそのツールを述べる.並行処理ソフトウェアシステムは 通常の逐次処理ソフトウェアシステムにはない多数の並行処理モジュールから成り それらが並行して多数のトランザクションを処理するソフトウェアシステムである.内部構造やアルゴリズムの選択・決定 およびその妥当性の検討という機能面での設計のためには 多数のトランザクションを種別し システム内でのそれらのルート作りを行い このルートを除々に詳細化する中で 排他的なアクセスを必要とする資源や購成要素を正しく識別し それらをさらに詳細化しながら 互いに並行的に稼働する並行処理モジュール群を定め 個々の内部でのアルゴリズムや実行手順を設計する.この機能面での設計とともに性能面の設計の作業が並行処理ソフトウェアシステムに対して特に必要である.このためには 機能面での設計に並行して徐々に明確となる資源の利用度合いや並行処理モジュールの実行時間などの見積りを正しく導入する.以上の並行処理ソフトウェアシステムの設計のために「ステップワイズプロトタイピング」手法を考案し パソコン上で並行処理ソフトウェアシステムのプロタイプを稼働させ 機能面での振舞いの評価を視認でき性能評価データの収集を自動化させるために Prolog言語とその処理系を活用したPFlots(Prolog based FLOW and Task Simulator)を開発した.

並行処理ソフトウェアシステムの設計段階に適用されるソフトウェアプロトタイピング手法とそのツールについて述べる．並行処理ソフトウェアシステムは多数の並行処理モジュールから成り，それらが並行して多数のトランザクションを処理するシステムである．機能面での設計のためには，トランザクションの種別・ルート作り，排他的なアクセスを必要とする資源や構成要素の識別，内部でのアルゴリズム・実行手順の設計が必要である．また，資源の利用度合いや実行時間などを見積り・評価する性能面の設計作業が必要である．以上の並行処理ソフトウェアシステムの設計のために「ステップワイズプロトタイピング」手法を考案し，パソコン上で並行処理ソフトウェアシステムのプロトタイプを稼動させ，機能面での振舞いを視認し，性能評価データを収集させるために，Prolog言語処理系を活用したP-Flots (Prolog based FLOw and Task Simulator)を開発した．A prototyping method and a tool are proposed for designing concurrent software systems. In concurrent software design process, the software designer is required to design the systems from both their function and performance aspects. As the design proceeds, the designer should recognize "tasks" each of which must be used serially and exclusively. We propose a "stepwise prototyping" methodology and a corresponding tool P-Flots (Prolog based FLOw and Task Simulator) for designing the systems. P-Flots executes the prototypes and visualizes their dynamic behavior and performance. The designer is capable of designing the systems in stepwise from their function and performance aspects with use of our methodology and P-Flots.