開発支援ツールの自動生成方式 のバックアップ(No.1)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 開発支援ツールの自動生成方式 へ行く。
  • 1 (2021-04-07 (水) 10:23:48)

---

「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

概要 †

本ページでは、種々の自動生成方式について纏める。

なお、ソフトウェア開発生産生の向上の取り組みは、

• コーディング・レベル
  • 自動生成
  • フレームワーク
  • テンプレート
  • .etc

以外にも広く行う必要がある。

この理由は、以下の技術要素も重要な生産性の変動要因であるためである。

• 提案（業務・技術面）
• フィージビリティ分析
• アーキテクチャ設計、処理方式設計
• 標準化
• 問題対応
• テスト
• 障害対応
• .etc

自動生成の用語定義 †

生成方式 †

リポジトリ型 †

各種リソースからリポジトリに情報を取り込むこともあり、仕組みは複雑になる。

• デザイナ操作型
  デザイナ操作で設計した画面項目やインターフェイスなどの情報を一旦リポジトリに取り込み、プログラムを生成する。

• スキーマ定義型
  画面項目やDBスキーマなどの情報を一旦リポジトリに取り込み、プログラムを生成する。
  

設計情報型 †

リポジトリが存在しないため、仕組みは単純になる。

• （Excelなど）設計書型
  設計書から設計情報を取り込み、プログラムを生成する。

• デザイナ操作型
  デザイナ操作から設計情報を取り込み、プログラムを生成する。

• スキーマ定義型
  DDL、WSDLなどの定義済みのスキーマの設計情報を取り込み、プログラムを生成する。

Visual Studioなどはドメインに特化した
デザイナ操作型（画面） + スキーマ定義型（DDL、WSDL）の
自動生成処理が中心に実装されている。

生成範囲 †

全層自動生成 †

P層、F（B）層、D層の全自動生成だが、
UI要素のレイアウトや、F（B）層のビジネスロジックはプログラマによって実装する必要がある。

ドメイン特化型全自動生成 †

特定のレイヤ（ドメイン）に特化した100％自動生成。

• デザイナ操作による画面初期化コードの自動生成
• スキーマ定義（DDL、WSDL）後のDaoやproxy等のコードの自動生成

100％全自動生成 †

P層、F（B）層、D層の100％全自動生成で、
且つ、UI要素のレイアウトや、F（B）層のビジネスロジックも
リポジトリから設計情報を取り込んで全自動生成する。

ツール毎の自動生成方式 †

Visual Studio †

特徴 †

Visual Studioの自動生成は、基本的に
Visual Studioデザイナ操作やスキーマ定義からの自動生成に特化している。
また、自動生成されるものの仕様も決まっており、カスタマイズ不要である。
このためテンプレート・エンジン等の仕組みは使用していないものと考える。

• 自動生成方式
  • ドメイン特化型全自動生成
    • デザイナ操作型
    • スキーマ定義型
    • デザイナ操作＋スキーマ定義型 Visual Studioデザイナを使用してWPF画面を作成するような場合。
      デザイナ操作（VSデザイナ）→スキーマ（XAML）→画面初期化処理自動生成

• 設計思想
  • 設計書情報が無いので、開発工程から活用
  • 各ドメインに特化した、開発視点の軽量型

• ポイント
  • ラウンド・トリップ非対応。
  • ドメインに特化しているためカスタマイズは発生しない
  • 従って、テンプレート・エンジンは使用しない。
  • .NET等、前提となるフレームワークを使用し生成量を抑えている。

UIデザイン系 †

• Windows Forms、ASP.NET WebForm?
  

• UIコントロールをデザイナを使用して配置していくと
  コードビハインドや、ASPXのASPタグにUI生成のコードが自動生成される。

• コントロールによっては拡張のカスタム デザイナが用意されており、
  それを使用して、UIのデザインと対応するUI生成のコードを自動生成する。

• WPF、Silverlight
  

• UIコントロールをデザイナを使用して配置していくとXAMLコードが自動生成され、
  ビルド時にXAMLからBAMLというバイナリ化されたXAMLが生成される。
  

• WPF、Silverlight実行時はBAMLを使用してUIの初期化が行われる。
  

• カスタム コントロールは使用せず
  ItemTemplate?、DataTemplate?などを駆使して
  カスタマイズ可能なアーキテクチャに変更されている。

データ・アクセス系 †

• DataAdapter:データ・アダプタ構成ウィザード

• TableAdapter:テーブル・アダプタ構成ウィザード

• Entity Framework

Dynamics †

CRM †

デザイナ操作型の100％全自動生成

• 画面定義からDBが自動生成される。
• 業務処理はJavaScriptでイベント定義

AX †

BRMS系 †

• 概要

• 業務プロセスはフロー、ルール、データから出来ている。
• 実世界の業務の中で、改修、改善が必要であったり、ビジネスの状況に併せて
  変更する必要があるのはフローよりもむしろ、ビジネス・ルールの方が圧倒的に多い。

• 構成要素
  • Manager（ルールの編集）
  • Engine（ルール・エンジン）
  • ルール・リポジトリ（ルール定義の管理）

• ルール・エンジン
  • ビジネス・ルールの実行をするフレームワーク、またはライブラリ
  • アプリケーションとビジネス・ルールの分離を実現
  • ダイナミックにルールを変更可能（アプリケーションの柔軟性を高める。
  • 多くのルール・エンジンはReteアルゴリズムをベースとする。
  • 定義したルールをプログラムから呼び出すと、入力から出力に変換される。

• BRM:Business RuleManagement?とは
  ルール・エンジンを含むビジネス・ルール管理をする環境
  • ビジネス・ルール・ライフサイクルをあらゆる側面からサポート
  • ビジネス・ルールの可視化
  • ビジネス・ルールのテスト
  • ビジネス・ルールの編集・デプロイ

• ルールの記法は以下の3つ
  • DRL：デベロッパ向け、ネイティブ記法、テキスト形式
    基本的に直接使用せず、以下DSL、Decision Tableから自動生成される。
  • DSL：ビジネス・エキスパート向け、自然言語、テキスト形式
  • Decision Table：デベロッパ、ビジネス・エキスパート向け、スプレッド・シート形式

• 特徴

• ユーザ・フレンドリ
  • 可視性　　：仕様定義≒ルール定義、実装への橋渡しが容易
  • テストレス：仕様系バグのみ対象、パンチ系バグはテストレス
  • 編集・デプロイが容易（≒EUC容易）

• ルールが頻繁に変わって可視化＆修正し易い製品メリットが
  通常のプログラムを上回る極狭い範囲で有用と考える。

自動生成方式毎の特徴 †

生成方式 †

自動生成ツールが何に重きを置いているかは、自動生成方式で大方、判断できる。

入力がExcel設計書の場合 †

モジュール設計情報が入力となるため、モジュール設計工程からの生成用途となる。

• メリット

• Excel設計書を選択する理由は
  設計と実装の乖離を防ぐ設計書からの生成のため。

• 設計工程からの設計書からの生成は、
  ウォータ・フォール的な開発プロセスには適合する。
  設計情報を修正しながらのラウンドトリップ開発は困難。

• デメリット

• しかし、100％全自動生成でなければ、
  • プロトタイピング、スパイラル、アジャイルなどの開発プロセスに適合しない。
    （これは、後述するようにラウンド・トリップ開発が困難であるためである）
  • モジュール設計レベルの工程が必須になり、場合によっては、
    キーパンチ相当の工程・スキルも２重に必要になる。

入力がデザイナ操作の場合 †

開発時の設計情報が入力となるため、開発工程からの生成用途となる。

• メリット
  • 入力にデザイナ操作を選択する理由は、
    設計と実装の乖離の防止ではなく、開発スピード向上（RAD開発）のため。
  • プログラマが開発ツールのスキルセットを満たすだけで良い。
  • 工程を跨がないので、ウォータ・フォールだけでなく、
    プロトタイピング、スパイラル、アジャイルなどの開発プロセスにも適合する。

• デメリット
  • 設計と実装の乖離を防ぐ仕組みは用意されていない。

入力がスキーマ定義の場合 †

開発時の設計情報が入力となるため、開発工程からの生成用途となる。

• スキーマ定義型の生成
  • XSDスキーマやコードの自動生成の入力とし、
  • （設計と実装の乖離を防止しつつ、）
  • 開発スピード向上（RAD開発）を向上させる。

• メリット
  • 入力にスキーマを選択する理由は、
    設計と実装の乖離と、開発スピード向上（RAD開発）のため。
  • スキーマ定義型の生成方式は仕組みも、最も簡単になる。
  • プログラマが開発ツールのスキルセットを満たすだけで良い。
  • 工程を跨がないので、ウォータ・フォールだけでなく、
    プロトタイピング、スパイラル、アジャイルなどの開発プロセスにも適合する。

• デメリット
  • 設計書と実装の乖離を防ぐ仕組みは用意されていない。

リポジトリを経由するもの †

最も大掛かりな仕組みではあるが、
リポジトリと専用設計ツールを組み合わせ、
100％全自動生成をサポートするツールが多い。

詳しくは後述のリポジトリ型を参照。

生成範囲 †

自動生成方式によって生成範囲が異なる。

全層自動生成 †

柔軟性はあるが、導入のために多くのサポートが必要。
社内の治工具ツールではこの自動生成方式が多い。

• 特徴
  • 受託開発で、いろいろな要件に対応する必要があるために
    プログラミングでの対応範囲を広げており、柔軟性を出している。
  • PJ毎、テンプレートのカスタマイズが可能な仕様となっていることが多い。
  • この柔軟性を発揮するには、重厚なサポートが必要になるが、
    重厚なサポートが可能となる社内の治工具ツールではこの自動生成方式が多い。

• メリット
  • 柔軟性がある。
    • テンプレート・カスタマイズが困難か、仕組みが用意されている。
    • 自動生成コードのカスタマイズが困難か、仕組みが用意されている。

• デメリット
  • ラウンド・トリップ開発への対応が必要。
  • 採用したツール・プログラミングの両方のスキルセットが必要。
  • このためEUC、設計・開発の分業の両方に適合しなくなっている。

ドメイン特化型全自動生成 †

ドメインに特化した範囲で100％自動生成なので、この範囲でプログラミングは不要となる。
サポートが容易になるので製品系ではこの自動生成方式が多い。

• 特徴
  以下の自動生成方式に多い。

• 社内の治工具ツール
  • EXCEL設計書型

• 製品
  • デザイナ操作型
  • スキーマ定義型

• メリット
  • 設計・開発の分業に向いている。
  • ラウンド・トリップ開発が不要

• デメリット
  • EUCに向いていない。
  • プログラミングと採用したツールに特化したスキルセットが必要。

• 柔軟性が低い
  • テンプレート・カスタマイズが困難か、仕組みが用意されていない。
  • 自動生成コードのカスタマイズが困難か、仕組みが用意されていない。

100％全自動生成 †

100％全自動生成なので、プログラミングは一切不要となる。
柔軟性に難があるが、サポートが容易になるので製品系ではこの自動生成方式が多い。

• メリット
  • EUCに向いている（と謳われることが多い）。
  • プログラミングのスキルセットが不要。
  • ラウンド・トリップ開発が不要

• デメリット
  • 設計・開発の分業に向いていない。
  • 採用したツールに特化したスキルセットが必要。
  • 定義がプログラミングと同等の作業が必要であり実際はあまり改善しない。

• 柔軟性が低い
  • テンプレート・カスタマイズが困難か、仕組みが用意されていない。
  • 自動生成コードのカスタマイズが困難か、仕組みが用意されていない。

リポジトリ型 †

生成範囲 †

• 以下のどちらのケースもある。
  • 100％全自動生成のツール
  • 100％全自動生成ではないツール

• ツールによっては設計情報の生成も可能になっている。

設計ツール †

リポジトリ型自動生成ツールの周辺設計ツール（DBや、Interface）の操作は

• 基本設計・詳細設計の設計工程の作業ではなく、
• モジュール設計工程以降の開発工程に近い作業であり、
• ツールの専門性も（ある程度）ある。

という事を考えると、

• 100％全自動生成ではないツールは
  開発スキルを２重に要する（デメリットがある）との見方もできる。

• 一方で、100％全自動生成のツールは、
  EUC用途での利用が想定されており、受託開発の工程の組み方と大きく異なる。
  
  • これらのツールでは、EUCで得られるメリットを最大化している。
  • トレンド的には、ピュアデベロップメントが衰退しEUCツールが隆盛していくと考えられる。

運用 †

リポジトリ型自動生成ツールでは、
リポジトリの運用（変更操作への対応）が困難と言われている。

• マージ
• ロールバック
• .etc

ツールの機能拡充で対応できる可能性もあるが、ツールは複雑になっていく。

テンプレート・エンジン †

• ポイント
  • テンプレート・エンジンの機構はJSPやASPで
    （Java、VBScript言語で動的に）HTMLを生成する機構に近い。

• テンプレート・エンジン・言語の習得が難しい事がネックとなり、
  EUC的なテンプレート・カスタマイズは困難。

• エンジン比較

• 独自テンプレート・エンジン
  • 言語が独自テンプレート言語となっており習得が困難。
  • デバッガの機能がないという問題があり、VBS化されるなどの事例がある。
  • 平たく言って → 難しい。

• Apache Velocityテンプレート・エンジン
  • 入力形式はJava（VelocityContext?経由）。
  • テンプレート側はVelocity VTL言語を併用する。
  • Console出力などを使用したデバッグは不可能。

• Eclipse JETテンプレート・エンジン
  • 入力形式はXML形式となっている。
  • テンプレート側はJava言語で習得が容易
  • Console出力などを使用したデバッグが可能。

• サマリ

• メリット
  専任者が自動生成の仕組みを沢山 [ 作る / カスタマイズする ] 場合は有用であると考える。

• デメリット
  • テンプレート・エンジン・言語の習得が難しい事がネックとなり、EUC的なカスタマイズは困難
  • このため、製品系ツールでは、柔軟なテンプレート・カスタマイズができるものは存在しない。
  • 採り得るアーキテクチャの多い.NETテクノロジでは、
    テンプレート・カスタマイズ方式では導入が困難である。

ラウンド・トリップ開発 †

Eclipse JETテンプレート・エンジンでは
行単位の追加・変更はラウンド・トリップ可能となっているが

• クラス・メソッドのシグネチャや、
• クラス・メソッド、XMLなどのエンティティの属性の

修正などの行内部の細かい修正については、ラウンド・トリップできない。

---

Tags: .NET開発, :ツール類, :その他、開発の色々

     

Site admin: dotNetDevelopmentInfrastructure

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.048 sec.