2016年9月13日火曜日

GeneXusインターナショナルミーティング GX26が開催されます

ご無沙汰してます。横井です。仕事が忙しくてブログの更新が滞ってました。

リオオリンピック・パラリンピックで南米が熱いですが、同じ南米のウルグアイで、いよいよ今年もGeneXusインターナショナルミーティングが開催されます。

今年は9月26日(月)からの3日間の開催です。先日発表されましたイベントのテーマは「Dream digital」です。サブタイトルとして「Dream Now」「Dream Together」「Dream Big」とあります。今回のイベントで正式リリース予定の新バージョン「GeneXus 15」を指しているのでしょうか。



毎年の事になりますが、今年は全くプレゼンの原稿が出来ていません。あと2週間しかありませんが、頑張って考えます。




2016年7月26日火曜日

【NEWS】日経ビジネスONLINE×ジェネクサス・ジャパン 連動企画 第3回目

「日経ビジネスONLINE&ジェネクサス・ジャパン 連動企画」第3回目の記事が公開されました。

以下、ジェネクサス・ジャパン社のプレスリリースから

2016年5月より開始となりました「日経ビジネスONLINE&ジェネクサス・ジャパン 連動企画」の第3回目の記事が本日2016年7月26日(火)に公開されました。

■日経ビジネスONLINE&ジェネクサス・ジャパン 連動企画とは?
2016年5月より、日経BP社が運営するウェブサイト「日経ビジネスONLINE」にて弊社と日経ビジネスONLINEの連動企画が開始となりました。
この企画では、経営者や役職者の方々を対象に、GeneXusの認知度向上やITの問題をGeneXusによって解決・改善できることをご理解頂くことを目的と致しております。日経ビジネスONLINEには全5回の記事掲載の予定です。

○日経ビジネスONLINE×ジェネクサス・ジャパン
【日経ビジネスONLINE SPECIAL「Futureproofing Your Business」】
― 第3回目 ― 2016年7月
http://special.nikkeibp.co.jp/atclh/NBO/16/genexus0527/p3/



2016年7月4日月曜日

【コラム】5) GeneXusの上手な使い方

話は戻りまして、GeneXusの上手な使い方です。そもそもの話は
開発経験が豊富な人、特に熟練のDB設計者はトランザクションオブジェクト=テーブルと捕らえてしまい、自分の頭の中でER図を設計しその結果をトランザクションストラクチャーとして定義してしまいがちです。
結果として、全くリレーションがないデータモデルが出来てしまったり、リレーションが張られても設計者が想定しないテーブル間でのリレーションであったりします。
でしたね。

では、どうすれば設計者が想定するようなデータモデルが出来るのでしょうか? ポイントとして3点あります。

(1)トランザクション定義においては対象業務の事実にフォーカスする

データモデルを意識してもいいですが、トランザクション定義においては一旦それは横に置いて、まずは対象となる業務処理(例えばデータエントリ処理)にフォーカスして項目・構造を考えます。これがユーザービューという考え方です。とかくエンジニアは内部構造を先回りして考えがちです。これをなんとか我慢しましょう。

(2)項目属性の名前付けは業務としての意味合いを追求する

GeneXusでは項目属性の名前付けは非常に重要です。項目属性に着けられた名前によってGeneXusが正規化処理を進めるからです。GeneXusの基礎教育(ベーシックコース)の中にも記述がありますが
・同じコンセプト(意味合い)のものは同じ名前に
・違うコンセプト(意味合い)のものは違う名前に
です。

(3)結果として出力されるデータモデルと自分が頭の中で想像するデータモデルを比較・検証する。

非常に不思議なのですがこのチェックを行う事により、アウトプットが正しくない=自分が正しいと思って定義したトランザクション(項目属性・構造)が実は業務のとらえ方として違っている。又は、自分が頭で思い描いたデータモデルは実はトリッキーなモデル(テクニックに頼ったデータの取り出し方をする)だという事に気付かされる事があります。


具体例として・・

受注トランザクションに商品情報を定義する場合「商品価格」という項目属性を定義します。しかし、「商品価格」は「商品トランザクション(商品マスタ)」にも存在します。すると、GeneXusは正規化処理を行って、「商品価格」は物理的には商品テーブルに配置し、受注テーブルには配置しません。

このモデルは正規化処理としては正しいですが、実際の業務としては正しいでしょうか?

商品情報はいわゆるマスタ情報ですが、「商品価格」は未来永劫同じ金額でしょうか? 商品価格=売価は月日の経過で変動する事もあります。先のデータモデルでは商品価格を変更すると、過去に登録した受注情報の商品価格まで変わってしまいます。既に決済が終わっている情報(特に金額に関する項目)が後から変わってしまうのは業務としては大問題になってしまいます。

商品価格が商品テーブル側にしか存在しないのが問題でしょうか? であれば、受注テーブル側にも商品価格を持つように変更すればよいでしょうか? GeneXusでは「冗長」をONにすれば、論理的に存在していないテーブル側に項目を持たせる事は可能になります。

でも、今回のケースではこの対応では間違いです。冗長とはあくまでも「同じ項目の同じ値を複数の場所で保持する」為のもので、問題のような時間が経ったら商品マスタテーブル側の価格は変更するが、受注テーブル側の価格は変更したくない。といったケースには使えません。

では、どうしたらよいでしょうか?
よくよくその項目属性に求められる「意味合い」を考えてみると、受注トランザクションに保持する商品価格は「受注時の商品価格」であって、商品トランザクションで持っている「商品価格」とは意味あいが違う事に気が付きます。

そこで、商品トランザクションは「商品価格」、受注トランザクションは「受注時商品価格」と名前付けをすると、GeneXusとしては別な項目と認識して正規化処理を進めます。
結果的に商品テーブルは「商品価格」が、受注テーブルには「受注時商品価格」がそれぞれ配置されます。

「名は体を表す」とはよく言ったものです。GeneXusでは意味合い(体)を突き詰めて考えるとそれに相応しい名前が思いつき、正しい名前が付けられればGeneXusが正しい正規化処理を行ってくれます。

業務に精通し、その業務で扱われる項目属性を正しく認識し、正しく名前付けられれば、設計のテクニック論に惑わされる事なく、正しいデータモデルを得ることができる。まさに、絵画における遠近法と同様の事をソフトウェア設計(データモデリング)でGonda氏は実現したのです。




2016年6月27日月曜日

【NEWS】日経ビジネスONLINE×ジェネクサス・ジャパン 連動企画 第2回目

「日経ビジネスONLINE&ジェネクサス・ジャパン 連動企画」第2回目の記事が公開されました。

以下、ジェネクサス・ジャパン社のプレスリリースから

■日経ビジネスONLINE&ジェネクサス・ジャパン 連動企画とは?
2016年5月より、日経BP社が運営するウェブサイト「日経ビジネスONLINE」にて弊社と日経ビジネスONLINEの連動企画が開始となりました。
この企画では、経営者や役職者の方々を対象に、GeneXusの認知度向上やITの問題をGeneXusによって解決・改善できることをご理解頂くことを目的と致しております。日経ビジネスONLINEには全5回の記事掲載の予定です。

○日経ビジネスONLINE×ジェネクサス・ジャパン
【日経ビジネスONLINE SPECIAL「Futureproofing Your Business」】
― 第2回目 ― 2016年6月
http://special.nikkeibp.co.jp/atclh/NBO/16/genexus0527/p2/




【コラム】4) ユーザービューとは? (GeneXusとDOA)

最近はあまりなくなりましたが、以前はよく「GeneXusってDOA(データ中心アプローチ)ですよね?」という質問を受けました。確かにGeneXusではデータモデルが大切で、設計・実装にあたってもそれが中心になります。(その理由は前回記事の通りです) でも、いわゆる一般的に言われるデータ中心「アプローチ」なのか? と言われると、「それはちょっと違うよ」と思っています。

そもそもDOAとは?

DOAでは、まず業務で扱うデータ全体をERモデル(Entity-Relationship model)によってモデル化し、それを正規化してRDB(リレーショナルデータベース)を設計する。
「IT用語辞典 e-wordより引用」http://e-words.jp/w/DOA.html


とあります。設計者がプロセス(処理)ではなく、データの構造に着目し設計(正規化)を行う方法なので、データ中心アプローチとなります。

一方、GeneXusではどうなるかと言いますと・・
これは2011年のGeneXus DayというイベントでGeneXus社の創業者で現会長であるGonda氏のスピーチで聞いた話です。(当時の模様はこちらをどうぞhttp://g-mind.blogspot.jp/2011/12/genexus-day-2011-winter.html)
今から遡ること30年以上も前、ソフトウェア業界だけが他の産業と違い家内制手工業がずっと続いている状況でした。(今も日本は同じ状況ですが・・) そんな中、Gonda氏は「このままではいけない。ソフトウェア開発にも産業革命が必要だ」と思い立ったのが、GeneXusを生み出すきっかけで、具体的にどうする事が(どういう方法論に基づいたツールを生み出すことが)その解決方法になるのか? と考えたところ、着目したのが絵画の世界です。

元々、絵画は芸術の世界で、描く人によってまちまちですし、それが芸術家の個性でした。ところがある時「遠近法」という技法が考え出されました。(近くにあるものを大きく描き、遠くにあるものを小さく描く) これにより、誰でも簡単に立体的な風景を描くことが可能になりました。

ソフトウェア開発にもこの様な「技法」を持ち込むことにより、誰でも簡単にソフトウェア開発ができないか? と考えて導き出されたのが「ユーザービュー(User View)」という考え方です。

「ユーザービュー」という人から見たシステムの外見(接点・インターフェイス)をそのままGeneXusに登録する事により、システムの内部(データの持ち方(DB設計)やデータに対する処理(ロジック))はGeneXusが自動的に生成する。というものです。

これにより、システム開発者は物理的な技術環境にとらわれることなく、現実の業務(彼らはリアリティ(Reality)と呼んでいる)にフォーカスしていけばよくなる。つまり、業務に精通する事がシステムを開発する上で重要な事である。という事が言えると思います。

GeneXusというと、とかくAIによる推論とかPrologとかが注目されることが多いですが、それらはあくまでもGonda氏の考える方法論を実現するための実装技術に過ぎません。

次回はGeneXusの上手な使い方についてです。