1A 一般発表セッション「開発手法・言語」およそ100席程度の広さの会場に70名程度が参加していた。 1A-1　組み込みシステムのためのソフトウェア開発ライフサイクル論松本吉弘氏（武蔵工業大学）今後の課題として、下記の点に注目すべきであるという話から始まった。・アドホックに情報拡大をし続けるサービス・サプライズソフトウェア　に対する政治、社会、経済的視野から反省(例えばY2K,飛行機事故など）・使い捨てでなく、　使いつづけを基本とする、ノーサプライズソフトウェアの設計・情報化社会を構成するに必要な情報技術マップ(ITマップ)の策定、認知・技術者像に基づく教育、資格この後の発表では、上記ノーサプライズソフトウエアの提供の必要性や、その設計手法・ライフサイクルモデルに関する話が主だった。現在のコード量は、1950年頃と比べて 10の9乗倍になっている。一方、商品のライフサイクルは数年前は18ヶ月だったものが現在では 3ヶ月になっており、さらにライフサイクルが短くなる傾向にある。対策として、ライフサイクルモデルを考え直さなければならない．従来型のモデルとしては下記のようなものがある。（１）ウォーターフォール（２）スパイラル（３）シンクロナイズ／スタビライズこれらに対して、新しいモデルとして、下記のようなものがある。・不定要求適応型（１）適応型（２）デイリビルドアンドスタビライズ・使い込みサービス（１）プラニングゲーム（２）究極計画型ここで使い込み型とは、例えば、携帯電話は捨てずに、ソフトウエアなどの中身を入れ替えて使いつづける、というようなものを言う。本発表では、下記のような、コンカレントアンドスタビライズ型と呼ぶライフサイクルモデルを提案している。 (a)要求分析　　　　　　→(b) (b)適応　　　　　　　　→(c) (c)コンカレントビルド　→(d) (d)スタビライズ　　　　→(e)または(b)へ (e)バックエンド上記では、要求分析後、job を複数に分けて同時に実装し、その後分けた job （の成果物）を統合する。これを繰り返し、安定性を高めていく。質疑応答Ｑ：作ったものを廃棄する時代は終わったと言われるが、　　捨てないハードウェアとして、どういったものを考えているか？Ａ：捨てるのではなく、新しい機能をうまく埋め込んだり差し替えたり　　できるようなライフサイクルを確立できればよいと思う。　　ハード側で実現するのは難しいとは思うが。Ｑ：コンカレントビルドアンドスタビライズ型ライフスタイルモデル　　において、「スタビライズ」から「適応」に戻るループがあるが、　　１．戻ると開発スケジューリングの管理が大変になると思われるが、　　　　そのことについてどう考えるか？　　２．すでに作ってしまったものを回収（改修？）しなければならなく　　　　なるが、その影響についてどう考えるか？Ａ：どのステージまで進んでいるかによる。　　戻れないところまできているのなら、次の製品（プロジェクト）　　で対応する。その決断をするための枠組みを確立することが重要。 1A-2　組み込み装置向きプログラミング言語 EBIFRY 大山博司氏（オークマ株式会社 FA システム事業部） EBIFRY の目標は、・ソフトリアルタイムからハードリアルタイムまで、一貫した容易な言語・安定性、応答性、可搬性の実現というもの。編集ツールは、WinNT / SunOS / Linuxで動作していて、 ITRONで動作する、マルチタスクＵＩを持っている。不具合の発生しにくくするために、・ポインタなし・オブジェクトの管理を自動化などの特徴を持っている。制御系の組込みには(動的故の)融通性よりも(静的故の)安定性が求められる。融通性のためには、記述性,抽象性,不定長オブジェクト,保守性,可読性が必要。融通性と安定性について、各言語をプロットすると下記のようになる。　高融通性　|　　　　Lisp 　| 　|PC C/C++ 　| 　|　　　　　　　　　　　Java 　| 　|　　　　制御系 C/C++ 　+----------------------高安定性制御系では、高安定性が必須。融通性は無くてもよさそうとのこと。安定性と融通性に対応するものとして、静的と動的についてまとめると下記のようになる。・動的オブジェクト：　必要なときに用意する　記述の局所性が高まり、可読性に優れる。・静的オブジェクト：　オブジェクトをあらかじめ用意する。　オブジェクトを動的に生成しないので応答性が高くなる。次に、時空間制約・安定性について、各種言語をプロットしてみる。　高安定性　| C/C++ 　|------------\--------------------------- 　| \ | 　| \ | 　| \ | 　| \ | 　| \ | 　| \ Lisp/SmallTalk/Java | 　| \ | 　| \--------------- | 　+---------------------------------------------時空間制約強 Lisp/SmallTalk/Javaは、制約が強くなると安定動作しない、限界が不明瞭、などの欠点がある。C/C++は、これに対し、制約が強くても安定動作する、限界点が予測できるなどの利点がある。 EBIFRYは、融通性を多少犠牲にしてでも安定性を追及し、静的な型やオブジェクトを基本としている。 EBIFRY のメモリ管理は、参照カウント方式を採用していて、下記のような特徴を持っている。・即時回収される・循環参照オブジェクトは回収できない・リスト、木は廃棄に時間がかかるまた、マルチヒープを実装していて、ヒープをオブジェクトの種類や目的によって複数に分けている。マーク＆スイープ方式(M&S)のメモリ管理を使わなかった理由としては、・ガベージコレクションの間プログラムが停止する・マルチヒープへの対応が難しい・M&S ではヒープを使い切る使用方法は誤りと考える・任意の時点でのメモリの使用量を知ることができないなどがある。質疑応答Ｑ：組込みではリソースをどの程度予約するかの予測が重要であるが、コンパイル後のメモリサイズの予測は可能か？Ａ：静的オブジェクトだから、ある程度は予測できる。ただし、文字列など、一部動的なオブジェクトも存在するので、最大メモリ使用量の予測は難しい。Ｑ：応答時間の見積もりは予測できるか？Ａ：ソフトリアルタイムのみの実装にとどまっているので、現時点では予測は不可能。応答時間の短縮よりも、メモリ消費量を抑えることを重視している。Ｑ：運用にあたっては、開発環境、検証環境が重要。新しい言語を設計しても対応するデバッガなどの周辺ツールも開発しないと、実際の運用ができないのではないか？Ａ：実は、Cのプリプロセッサとして実装されている。なので、 C のデバッガが使える。また、実機上ではスタックトレース機能を持っている。Ｑ：静的オブジェクトだと、頻繁に利用しないオブジェクトも常にメモリ上に確保しなければならないので、かえってメモリを多く消費しないか？Ａ：M&S は実際に利用するメモリの2倍の実メモリが無いとうまく動かない。そのことを考えれば、参照カウント方式のメモリ管理を行う EBIFRY の方がメモリを消費しない（かもしれない）。大きなものを作ってみないと、はっきりしたことはいえないが。 (1A以上)