SLP記述
Q
SLPはソースコードを生成してくれますか？
A
ソースコードの生成はできません。
SLPは仕様を記述する（＝論理無矛盾かつ統一的用語で記述する）ためのツールであり、設計をするためのツールではないためです。
設計は機能を実現するためにプログラム言語との連続性を意識した作業といえます。
この作業を行うために考案された設計言語の中には、特定のプログラム言語と対応関係を付けることができるものがあります。
多くの人はこれを形式手法と考えられているようです。これは仕様記述言語と言われているものです。
Q
SLPが自然言語にこだわるのはどうしてですか？
A
既存の仕様記述言語の多くは、SLPでいう論理矛盾や用語の不統一の問題をクリアし、かつそのデータの型まで厳密に定義できるようになっています。しかしこうなってくると、仕様の企画を検討したりする場合、もしこのような言語で記述するのであれば、この専門的な仕様記述言語を知らないと、レビューには参加できません。もし万が一要求仕様の記述レベルでこのような言語を使っているとすれば、仕様のレビューをする場合には、もう一度自然言語で書きなおす必要があるでしょう。
要求仕様の検討過程は動的な試行錯誤のプロセスです。分野を超えて議論する必要がありますので、意思伝達メディアとしては自然言語以外には使用できない場です。
しかし論理的な厳密さも必要です。かつ誰もが可読可能なものである必要があります。そうなると自然言語に近いものとなります。SLPはそれを実現しようとしています。
もっともSLPには可読性があると言っても、中には、”if-else-endif”を見せつけられてはたまらないという企画の方もおられるかもしれません。しかし既存の仕様記述言語よりはまだ格段自然言語的であるというのではないでしょうか。特別な教育も不要です。
Q
”if-else-endif”構文がどうしても必要ですか？
A
はい、必須です。SLPではif-else-endifのみではなく、if-else-endifの中を構成する文の主語や述語を明確に書くことを義務付けています。任意の用語が文書全体の中で、統一的に書かれ、かつ任意の文も他の文と論理矛盾なく関係付けられているようにするためです。
そもそも仕様書の世界は条件の世界です。よって”if”は必須です。しかし、SLPでは”if”以外のケース、すなわち、”else”を強制的に付加することにより、条件の網羅性を保証しています。よって、”if-else-endif”構文は不可欠です。
さらに、SLPの条件の網羅性は、”if-else-endif”が何重にも重なったものを、決定表として出力し、日頃見慣れた表にする機能も備えています。こうすれば可読性はグンと高まります。
Q
”if-else“のネストが深くなり、自分がどこにいるのか、つまりどういった論理について今考えているのか、わかりづらくなってしまう、ということはありませんか？
A
現在のSLPのパンフをご覧になってのご質問のようですが、そのご指摘はもっともです。ネストが何層にもなれば、条件が多くなり、どんな条件に今あるのか、“迷って”しまいます。そこで、ネストは３つくらいにして、それ以降はFn（単位機能）の中で展開（ネスト）するように書いたらいかがでしょうか。２の３乗個、すなわち８ケース程度のことであれば、そのうちの個々のケースがどのような条件（３条件）からなっているのかが、理解できるのではないでしょうか。そしてさらに深いネストの場合には、その８ケースの中の１つが、また３層のネストを持って、という具合に、深いネストによって”迷子”にならないように、手立てをすることができるのではないでしょうか。
Q
SLPと既存の形式手法の使い分けはどうしたら良いですか？
A
SLPは仕様の「意味」にフォーカスしています。
他方既存の形式手法は設計と連続することを意識していますので、仕様の「実現法」にフォーカスしていると認識しています。
しかしこれらは対立的なものではありません。補完的であると考えています。
SLPで意味を確認してから（論理無矛盾＆用語統一）、既存の形式手法を利用したらよいのではないかと思います。
しかし両者は連続していません。SLPでは、仕様の規模と複雑さが増大して今日では、仕様内容の整合性の獲得にフォーカスすべきと考えています。仕様を正確にして、また変更にもすばやく仕様を正し、実装のプロにプログラミングと設計の仕事を存分に委ねるべきかと考えています。
Q
自然言語で書かれた仕様書をインポート、エクスポートすることはできますか？
A
できません。今後言語処理ソフトとの連携を図ることができればと考えています。
出力に関しては、助詞や助動詞や、また”if”や”else”の接続関係を単純に補完したものは出力するものはできますが、 結局は最後は自分たちで手直ししなければならないと思います。従って、止めました。自然言語は難しいですね。
Q
話題沸騰ポット以外にも様々なパターンのサンプルがほしいのですが。
A
練習問題 やパンフレット等にslpファイルを掲載していますので、御参照ください。
Q
複数人（担当別）作成の文書を統合できますか？
A
はい、できます。単位機能の結合というSLPの機能を使用することで、複数のSLPファイルを１つにまとめることができます。
事前に仕様範囲の分担を行い、各々が仕様の獲得、確認、記述を行います。
このような作業を最後にまとめる段階で、SLPにはメンバー名と状態名の文言を置換する機能がありますので、 各人が同じことを別のコトバで記述していても、あとで統一することができます。
もし用語が分からなかったなら、メンバー名や状態名にｘ、ｙなどの変数を書いておいて、 あとで一括して適切な用語を代入（置換）することができます。
Q
仕様記述法であるUSDM(Universal Specification Describing Manner)でこれは活用できますか？
A
XDDP手法をお使いの方が、SLPはUSDMとして活用できるとおっしゃっておりました。私どもも同じ認識です。
XDDPの要求仕様記述方式は特定の様式に定めていないようで、自然言語等自由であるとお見受けしました。
仕様の理由を書いて、仕様内容の意味内容をよく認識するという規範のようです。
XDDPの規範にSLPの様式を付加したらいいのかもしれませんね。
SLPでは、変更内容を統一的に記述し、かつif-else-endifで網羅的に記述することは 派生開発であろうが、新規開発であろうが必要であると考えております。
大規模開発
Q
検査の処理時間はどれくらいですか？
A
以下の規模のSLP仕様書で処理速度の試験をしました。（公開はできません）
総行数 21,102
Fn文数 1,603
Do文数 5,445
if文数 3,021
switch文数 39
case文数 235
elsw文数 39
loop文数 303
exitlp文数 303
また検査を行う際の、関連する要素情報は、下記です。
Do,Fn,exitlp文の総数 7,351
検査した総パス数 1,686,662,794
検査した総条件数 6,206,672,213
《内訳》 単純検査 ( 各パス内での条件の冗長、矛盾検査 )
検査したパス数 252,914
検査した条件数 216,253,463
パス相互間検査
検査したパス数 1,686,409,880
検査した条件数 5,990,418,750
本SLP仕様書記述の基づいたプログラム規模
総ステップ数、５１．１K、コメントなしの実ステップ数３２．６K。
検査時間
if文やcase文など条件分岐が多くなると処理時間は増えます。
《実行環境１》 Valuestar G/プロセッサ Intel(R) Core(TM)2 Quad CPU Q9550 @2.83GHz 2.83GHz
メモリ 4.00GB/システムの種類 32ビットOS/OS Microsoft Windows Vista Ultimate 2007 Service Pack 2
【検査時間】 9分10秒（全項目検査）
《実行環境２》 Lenovo/プロセッサ Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz 2.99GHz/メモリ 1.99GB RAM
システムの種類 32ビットOS/ＯＳ Microsoft Windows XP Professional Version 2002 Service Pack 3
【検査時間】 20分（全項目検査）
Q
SLPの形式手法では大規模開発には向かないのでは？
A
いいえ、Q&Aに記載の検査処理時間の結果例のようにSLPは大規模開発を念頭においています。
また多人数でSLP文書を作ったとしても、それらのファイルを容易に結合し、論理矛盾の検査と用語の統一を図ることができます。
Q
協力会社でSLPを持っていない場合にはどのようにしたらよいのですか？
A
SLPをPDF化することは可能です。また、SLP Readerを開発しており、現在テスト中で近日公開予定です。(2014年2月現在)
形式手法
Q
このソフトを使って仕様書を書いた場合、形式手法に則った仕様書であるといえますか？
A
はい。形式手法の定義にもよりますが、形式手法であると認識しています。
SLPは今までにないものですから、既存の形式手法と異なるので、形式手法ではないと思われるかもしれません。
今までの「形式手法」はすでに述べたとおり、仕様を実現可能な設計書として記述する言語であると思います。
それに対してSLPは仕様自体の意味関係を明確にすることに焦点をあて、意味の論理無矛盾と用語の統一を図ることを目的にしています。
Q
従来の形式手法との違いはなんですか？
A
通常「形式手法」という場合、多くの方はソースコードの自動生成を要件に挙げるようです。
繰り返しになりますが、SLPは仕様をまずはっきりさせましょう、という考えで、設計ではなく、要求内容そのものにフォーカスをしており、これが従来の形式手法との違いです。
その理由は、私どもの認識によれば、大規模システムにおいては、ソースコード以前の仕様内容そのものが問題であり、かつ設計仕様と要求仕様には、実現するための方法と実現して欲しいことの内容、という違いがあります。しかし開発現場では「信用に足るのは最後はソースコード」となるのですが、システムの規模が大きくなり過ぎた今日では、ソースを見ることのできる”ベテラン”も手に負えない状態です。ですから、仕様をキチンとかつ誰もが分かりやすく、統一的に迅速に書くこと、かつ理解することが求められています。 この上で、SLPと設計に目を向けた従来からの通常の「形式手法」とがうまく連携すると思われます。
Q
論理整合性を確認するベースとなる技術はなんですか？
A
論理学の意味論（真偽論）です。また文を主語（目的語）と述語に分けて、個々のコトバの検査ができるようにしているところに新規性があろうかと思っております。文書の中には主語や目的語が、述語を伴いあちこちで意味を発している、そんなイメージで文書をとらえています。主語や目的語をメンバーと呼んでいます。文の要素です。この要素に述語（属性）がくっつき、接続詞の”もし”や”かつ”や”でない”が絡んで、我々は意味を発しています。しかし、時に矛盾に満ち、曖昧に、あるいは美しい形容を持ちます。SLPはこれを無矛盾に、正確にするという訳です。美しい気の利いた比喩は使わないことになるでしょう。
その他
Q
詳しくSLPを知りたいのですが、当社まできていただきプレゼンテーションをしていただくことは可能でしょうか？
A
はい。ご用命の際は、slp-support＠jfp.co.jp までご連絡ください。(＠は半角文字に書き換えてください)
Q
setup.exeを実行してもインストールできないのですが？
A
SLP_***.msiを実行してインストールしてください。（***はバージョン表記）
Q
『WindowsによってPCが保護されました』と表示されインストールできないのですが？
A
1.WindowsによってPCが保護されました”とメッセージが表示されたら『詳細情報』をクリックします。
