SQLをフローチャートに
竹内義晴氏のコラムにコメントさせていただきましたが、プログラミングは料理に似ている。
料理に慣れている人はレシピなんて見ないし、レシピから作るなんてことはしない。
再現する（他人に分かってもらう、自分が忘れない）ためにレシピが必要なだけです。
「仕様書のとおり作ったらよい」という杓子定規な考え方は、レシピに白身魚と載っていたときに、魚屋に「白身魚をください」って買いに行っちゃうようなものですが、レシピの書き方だけ、レシピの再現の仕方だけを別々の人に要求するIT業界は、そういう人を生み出して技術者と呼んでしまう。
かなりいびつでしょう。
調理、サービスと分けて専門分野としていった方が、断然進化すると思うのです。
持論としては、基本設計 ＝ SQLなので、基本設計まであればいい。
つまり、わたしにとっては基本設計がSQLに見えていたわけです。
そうは見えない人を理解していなかったわたしは困ったオッサンですが、見えないのが当たり前と言うところに立ち返って、SQL文構築法をエンジニアリングしていっています。
脳内ではかなりできた。
作ってみると、SQLって本当に単純な構造で、あまりに枚数が少なすぎて、どうやって水増ししようかと悩むぐらいだ。
しかし、わたしはパワーポイントなどが苦手でモノになるのはもう少し先かな。
当たり前の話かもしれませんが、エンジニアリングしていくとSQL文を作る工程はフローチャートになります。
＃ ってことは対話式のウィザードも作れなくもない。
＃ 直で書いた方が早いから、個人的には
＃ 想像すらしなかったけど、案外ニーズがあったりして。
このフローチャートの分岐の部分でエクセルを使って、実際のエンジンの動きを確認していけばSQLが書ける、というものです。
わたしが頭の中でやってきたことを、多少、分かりやすく（回りくどく）したものなのですけどね。
大阪のセミナールームは確保できそうですので、受講者が確保できそうなら……。
資料を急いで作ります（笑）。
コメント
インドリ
どうも、こんばんわ。
>対話式のウィザード
残念ながら既にあります。
VSとかSQL Serverの付属ツールとか・・・
でもこれって「汎用」なので、結局は自分で書いたほうが早くなります。
>SQLをフローチャートに
ここが驚きです。
集合指向言語SQLをフローチャートに！
これって画期的だと思います。
ビガー
ビガーです。
記事に以前のような熱さが最近感じられず個人的にちょっと残念です。
設計をどのようなアプローチでやるかは各人の好みですが、私が好きなのは
目的別のユースケースを各々定義してそれらをマージしていく。
このマージをロバストネス分析ちっくにBoundary/Control/Entityに
分割しつつ統合していくと全体を俯瞰できる基本設計の概要が出来上がります。
(マージ作業が腕の見せ所)
で、横断的関心事を見抜いて分離しつつアーキテクチャを実装しながら、
ユースケースの優先度に従って細かいアプリを実装していくってな具合です。
ここで重要なのはアプリの実装はほとんど素人でもできるような代物まで
アーキテクチャがサポートできていること。生産性/品質が格段にあがります。
たぶん、SQLで基本設計を考えるというのは、Entityを中心にControlや
Boundaryを決めていくのでしょうけど、全体像の把握とか横断的関心事を
実装する責務はどのように決めていくのでしょうか？
SQL文の組み立てって、何らかの目的があってその目的と関連するEntityを
抽出して、その中でどのEntityを軸にどうやってその他のEntityと結合させるかを
繰り返す作業でしかない考えています。
要するに基本設計の要素としてはやっぱり適合しない気がします。
東京でもセミナーやって私の偏見を変えて下さい。
example
SQLは宣言型言語ってのが大きいんじゃないですかね?
ビガーさん、おはようございます。
基本設計 ＝ SQL というのは、実は間違いで、
基本設計 ＝ SQL － UI
ですね。
基本設計をSQLから考えるのではないです。
私は基本設計を考えるときは、先ず、横断的にUIで要件を満たすこところから入って、UIを引いたらSQLが残っているイメージです。
一般的には残った部分をバラバラに分解して……。
分解した時点で後戻りはできないけれど、分解することが目的化していることも多い。
インドリ
>全体像の把握とか横断的関心事を
実装する責務はどのように決めていくのでしょうか？
ちょっと反応したくなりましたので書きます。
SQLは集合理論で考えられたものです。
逆に全体像の把握とか、横断的関心事は集合の得意とするところだと思います。
ちなみに、オブジェクト指向も集合で考えられます。
なので、SQLというよりも集合で設計は考えるといえるのかも。
インドリさん、ども。
基本設計 ⇒ SQL になっても、SQL ⇒ 基本設計にはならないと思います。
設計するときの考え方として集合というのは重要ですね。
小さくして積み上げる人が多すぎるように思いますから、集合というより、「もっと全体を見ろよ！」ってことなんですけれど。
ビガー
ビガーです。
集合理論うんぬんはよくわかりませんが、集合の作り方が腕の見せ所かな。
ただし、実装の視点だけではいびつな集合になってしまう。
そのお客様の業務(集合？)では、どの業務が軸となるものなのか、
その軸となる業務に他の業務をどう結びつけるのか。。
ユースケース＝業務なのでアプローチとしてはほぼいっしょになりますね。
ちなみにある程度の規模の業務が絡み合うと目に見える形で整理しないと収集が
つかなくなると考えています。その癖づけのためにもどんなに規模が小さくても
私は脳内で済ませず、皆が見える形にすることを習慣化しています。
インドリ
いい意見がかえってきて嬉しいです。勉強になります。
>基本設計 ⇒ SQL になっても、SQL ⇒ 基本設計にはならないと思います。
仰るとおりだと思います。
やっぱり、設計と実装は両方出来ないと駄目ですよね。
＞私は脳内で済ませず、皆が見える形にすることを習慣化しています。
チーム開発において、このビガーさんの習慣は非常にいいと思います。