自動化システム 圧倒的な生産性

圧倒的な生産性

数学的な集合を基盤とする内部のテクノロジーにより開発を圧倒的に効率化しています。
また、自動化やソフト資産を駆使した小規模のソフトウェアパッケージの開発・販売も承っています。

自動化による高速開発に強みがあります。オンラインでのビデオチャットやオンライン資料を用いた学びについて承っています。また、自動化やソフト資産を駆使した小規模のソフトウェアパッケージの開発・販売も承っています。

目次

圧倒的な生産性

数学的な集合を基盤とする内部のテクノロジーにより開発を圧倒的に効率化しています。演算的にシステムの合成や差分の管理ができる特徴があります。また、MySQLのような集合を記述可能な言語で記述されたシステムとの合成が可能です。

開発に用いている集合システム

簡単な例を示しますと例えば下のような内部言語でプロジェクトを管理しています。集合を扱いやすいSQLと重複部分は多いですがSQLにない記法をいくつか拡張しています。

$groups &object &labels {
  id:unit;
  name:string /key;
  parent_id:unit?-groups.id;
  parent_name:string :="parent.name";
  members:members*-members.group_id;
  subscribers:subscribers*-subscribers.group_id;
}

このような形で複数の集合やその関連を定義していきます。集合型なので継承ではなく、Aspect指向に近いアプローチです。また、テーブルやViewの処理と相性のよい手法です。合成の手法としてアーベル群で一般化する手法をとっています。もともとは逆解析と呼ばれる数値計算に適用することを考えて考案された記法なので、Webシステム以外にも様々なものを記述可能で、システムインテグレーションに適しています。

システムインテグレーションのアプローチとしてはプロジェクトや集合を演算的に合成する手法を取ります。プロジェクトはテンプレート単位で管理しています。合成の種になる集合のテンプレートとしては、下のシステムレベルのテンプレートから、各種共通機能などのコンポーネントレベルのテンプレートまで様々なものがあります。

操作画面

実際の開発のツールは上のようなものを用いています。視覚的に確認しながら作業を進めるため、モデリングにおけるミスが発生しにくくなっています。

基本的なコードは自動生成されますが、UIの調整のための生成エンジンもあります。例えば、UIは次のようなツールで生成します。

UI生成

モデリング環境

実際のモデリングのツールとしては上のようなものを用いています。視覚的に確認しながら作業を進めるため、モデリングにおけるミスが発生しにくくなっています。

自動生成システム

基本的なコードは自動生成されます。laravelで開発をする際に必要となるものは一通り自動生成されます。

部品生成システム

UIの調整のための生成エンジンもあります。例えば、UIは次のようなツールで生成します。

定型的に生成されるコードであるため、ミスは小さくなっています。また、多数のシステムを結合した状態のシステムを細かく分割しているため、あとでシステムインテグレーションすることが比較的容易となると考えられます。

採用している集合型モデリングについて

集合とクラスの最大の違いは直積に分解できるかどうかということで、集合からクラスへの変換はできますが、クラスから集合への変換はできません。直積に分解できる写像が定義できるというのは逆写像が存在することを意味していて、そのプログラミング上の意味は双方向バインディングできるということです。同型写像であれば、中間形式でエントロピー落ちがなければ自明に直積が存在し、双方向バインディングが可能です。実装にエントロピー落ちがないかの証明は M M^-1 のテストシナリオを全ての境界値に対して書けばできます。

SQLは一階述語論理なので、 join × where × offset × limit というように直積に分解でき、逆写像も定義できますが、クラスには自分で定義しなければそのようなものは存在しません。また、SQLで定義したviewに対する追加や削除などの操作は参照するtableにも反映されますが、オブジェクト指向で同じ要件を満たすのはSQLほど簡単ではありません。システムの終端ストレージがSQLである場合、webシステムがエントロピー落ちのない同型写像であることを論理的に証明するにはweb上からSQLを実行できればよいということになります。なお、よくある勘違いですが、セキュリティはエントロピーとは関係がありません。アクセスしてはいけない人のローカルデータとリモートデータが双方向バインディングされてはいけないので。つまり、同型写像プラットフォームにおいては制約条件も写像されるべき対象であるということです。例えばサーバ側で不正値であるデータはクライアント側でも不正値であるこということです。例えば投稿の文字数上限が500文字という制限をイメージするとわかりやすいですが、ブラウザでも入力値チェックをし、サーバでも入力値チェックをします。このように端末やルーターやスイッチやロードバランサやWebサーバやSQLサーバなどアクセスするハードウエアの数だけ実装の重複が発生しやすいため自動化というのは効果的なアプローチとなります。

また、デバイスがわかれる場合、そのデバイスを制御するための記法はすべてまちまちです。一つの要件から派生して生じる要件というものがフラクタル的に増えていく特質があるため、全体を体系的に俯瞰しながら実装していく必要があります。様々なレイヤーのプロフェッショナルを多数抱える企業様であれば問題ありませんが、少人数で進める小さい案件になると全体をカバーするのが大変になります。自動化なりエージェントシステムなりにより、このような手間を省けます。また、サーバサイド、クライアントサイドの担当者がわかれる場合に生じるコミュニケーションコストがなくなることで、より実際的な価値の部分に集中できます。

このような集合を用いた処理が特に向いているのは業務データ処理系や厳格な数値計算系、非集合処理が向いているのはゲームや組み込み領域です。集合型でもオブジェクト指向型でも同じキーワードが頻出しますが、同じキーワードでもアーキテクチャが異なれば全く別物になります。例えばSQL文の中の if expression はフィルタですが、C言語の中の if statement はフィルタとは限りません。集合型は宣言型に書き直せますので、内部処理を除けば破壊的代入のない記法となりますが、組み込みやハードウエア実装ではメモリを節約などするために可能な限り破壊的代入をしますし、目標とするゴールが大きく異なります。