＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「UML」を初めとする現在の「モデリング言語(手法)」の問題点は？
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-02-09 04:41
同じく。
Rightプロパティがgetのみなのは、「描写の起点と量を指定してください」というソフトウエア側のルールでしょう。Moveメソッドなしなのは「再度描写の起点と量を指定してください」ってことでしょう。
の意味するところですが、「右の位置は左の位置プラス幅」というルールを採用し、フィールドを左と幅の２つにした場合、 ＞・振舞２：サイズ変更（方向 as 角度，変更量 as 長さ） は、方向が左なら左と幅が、方向が右なら幅だけが変更される。 ．．．となりますね。 つまり、「右の位置は左の位置プラス幅」のルールが「情報：右の取得」と「振舞２：方向が左のケース」に分散されます。 「幅は左と右の距離」というルールを採用し、フィールドを左と右の２つにした場合、 ＞・振舞２：サイズ変更（方向 as 角度，変更量 as 長さ） は、方向が左なら左だけが、方向が右なら右だけが変更される。 ．．．となり、実際に幅が変更されるのは「情報：幅の取得」の時であり、「幅は左と右の距離」のルールが分散しません。 こういった問題が発生するのはオブジェクト指向Ｂ型の欠陥でしょうか？ ．．．と問いかけているつもりです。 | ||||||||||||||||||||||||
|
投稿日時: 2005-02-09 06:39
同上。
この話は、逆に強烈な規約でルールを締結すれば プロパティは使いやすい・・・と言うニュアンスをはらんでいるのでしょうか？ デザインパターンで言うSingletonとか、Stateがもろそれなんじゃなかろうか・・・？ （Propertiesクラスが確かHashだったかな・・・？ 結構つくりがずさんと言う噂を聞いたことがあるようなないような・・・。汗） どちらにしろ、仕様が潜在意識レベルで強烈に規約化されているのであれば プロパティは使いやすいでしょう。（個人的な結論） しかし、応用させようとすると、その規約が邪魔になるので、 やはり場合によりけり・・・かな？ 個人的には、使いやすく製作・製造する際のひとつの手法で、 亜流・・・なのかな？と思います。 例えがあってるかどうかわからないけど、 Strutsが近いかな？ 設定ファイルだけ書き込めばかなり勝手に動いてくれる。 しかし、設定が一箇所でも違うのであれば、頁がまともに表示されない。 それだけでは飽き足らず、正常終了していないにもかかわらず、 正常終了に見せかける細工とかしてあったり・・・。 でも、覚えたら簡単なんですけどね。 ただ、それを共通認識化して、全員に手間暇かけさせる事の費用と利益の関係は・・・？ 一点気になるのは、 javaは全てのプログラムが public static void main(String[] args){ } から始まるって事かな？（笑） 振る舞いから始まってんじゃん。ヾ(*^▽^*)ﾉわはは [編集] String args[] →String[] args 徹夜明けは寝ぼけてるな。（汗） [/編集] [ メッセージ編集済み 編集者: るぱん 編集日時 2005-02-09 06:44 ] | ||||||||||||||||||||||||
|
投稿日時: 2005-02-09 08:52
使いやすい．．．かもしれない。 プロパティの是非とは関係なく、ですけど。
素人なのでよくわかりません。（笑）
私はゴミステーションの当番で早起きです。（笑） | ||||||||||||||||||||||||
|
投稿日時: 2005-02-09 09:34
本田＠スミテムです。
確かにオブジェクトは振舞いではないですね。 オブジェクトは状態と振舞いを持ちます。 そして、未記人様は「状態」を隠蔽し「振舞」を通じ、私は「状態」が観察できることを以って公開しているという違いだけです。
(ここから追加) 「存在」＝「状態」だというのが私の考えですので、これが是ならA型(振舞のみ)の方は「状態」を「振舞」で取得するのと同様、「存在」も「振舞」で取得しなければならないのでは思ったのです。 (ここまで追加) この前提には、A型(振舞のみ)の方は、文字通り「振舞」のみで世界を認識されていると考えていたことがあります。 「存在」が「振舞」以外の何かでは不都合ではないかと感じたのです。 ところが、
「存在」＝「状態」ではなく、「存在」＝「所与の前提」とお考えなのですね。 (さらに追加) #厳密には、 #ルートの「存在」＝「所与の前提」 #ルート以下の「存在」＝「振舞」 (ここまで) とすると私のこれまでの表現が誤りで、 A型(振舞のみ) ではなく A型(所与の前提、振舞) と修正させていただきます。
繰り返しになりますが、ドメイン空間を包含する何かのオブジェクトの「状態」になります。 大切なのは、包含関係をマクロに広げることではなく、手持ちのカテゴリで論理が閉じるかどうかを検証することです。 A型は、手持ちのカテゴリである「振舞」だけでは、論理が閉じず、加えて「所与の前提」が必要だったようで、私のA型の定義が誤っていたようです。 B型でしたら、手持ちのカテゴリ「状態」「振舞」によって論理を閉じることができます。
「所与の前提」ということで納得されており、例外と感じないとのことですので、これ以上私からは申し上げることはございません。 コメントありがとうございました。 おかげ様でA型の定義を修正することができました。 以降は、未記人様以外のA型の方のご意見に耳を傾け、このお話を検証していきたいと思います。 言葉足らずを追加 [ メッセージ編集済み 編集者: 本田＠スミテム 編集日時 2005-02-09 09:44 ] さらに追加 [ メッセージ編集済み 編集者: 本田＠スミテム 編集日時 2005-02-09 10:50 ] [ メッセージ編集済み 編集者: 本田＠スミテム 編集日時 2005-02-09 12:52 ] | ||||||||||||||||||||||||
|
投稿日時: 2005-02-09 10:01
コナンです。
寝る前にふと思ったのですが、《全角カタカナを半角カタカナにする関数》の ルール、作戦、プレーヤーの例が間違ってました。 ルール：文字コード 作戦：文字列を変換する プレーヤー：全角カタカナを半角カタカナにする これならどうでしょうか。 昨日の例ではプレーヤーに雑用をさせてしまってました。 （まだ振る舞いっぽいですけど  ）
| ||||||||||||||||||||||||
|
投稿日時: 2005-02-09 12:20
左位置,幅,右位置は良き例題ですね。
私の意見を述べますと、 まず先に左位置に対する概念を理解します。位置を考える場合、 絶対軸に対する「絶対位置の概念」と距離指定による「相対位置」の概念の どちらで理解し捉えているのかを認識しなければいけません。 私は配置概念を持つオブジェクトは全て相対位置の概念で捉え、 配置元とは一方向性（関係の方向性）の親子関係で捉える事にしました。 また親子関係に於いて最上位にあるオブジェクトは左開始位置の概念はありません。 これは自分が配置概念を必要とせずに自分に配置されるオブジェクトに 相対位置を教える為に存在するだけであり、 地球に絶対的左位置が存在しない事を想像して頂ければ宜しいかと思います。 例題を戻し考えましょう。 ウインドウに於いて、左右の相違関係が重要なのか？、左右個別の位置関係が重要なのか？ この時点では、どっちでも良い様に思えます。 （続く） [訂正]： 1.（関係の方向性）を追記 2.右開始位置→左開始位置 に訂正 3.絶対的右位置→絶対的左位置 に訂正 _________________ OFF企画中ご意見募集 [ メッセージ編集済み 編集者: はにまる 編集日時 2005-02-09 12:46 ] | ||||||||||||||||||||||||
|
投稿日時: 2005-02-09 12:24
そこで更に別の設問で考えてみます。
「配置元のサイズ幅が100の場合にサイズ幅200のオブジェクトは配置出来るか？」 出来ないと答えた方は配置オブジェクトに「枠」の概念を持たれていると思います。 私は出来ると考えました、これは配置空間と表示領域は別であると捉えた結果です。 配置空間では数値上の概念であり数値表現が可能な範囲内に於いて 子オブジェクトの配置が可能です。 そして表示領域の開始地点は配置空間に対し固定ではありませんが、 一般的に配置空間の座標０地点に置かれ、 親の表示領域範囲の制約を子は引継ぎます。 この考えは、 自分が泳ぐポジションから視野の範囲に於いて海が見える。 視界外では海が滝の様に流れ落ちている訳では無い。 水中眼鏡をかける事により視野が狭まる。 泳ぐと景色が変わるが、海が移動している訳では無い。 目の前にマンタがいた、私の水中眼鏡から見える視界範囲に収まらない程に巨大だ しかし巨大なマンタの体は私の視界外で体が途切れている訳では無い。 と考えれば宜しいかもしれません。 再度、左位置、幅、右位置の話しを戻しますと、 つまり、私が認識している世界では視野の開始位置（左位置）と範囲（幅）が 重要であり、開始終了点（右位置）に意味はありません。 私にとって右位置の属性を定義する事は、 実装を意識した設計上の配慮であり、分析要求の結果では無いと云う事です。 [訂正] 1.そこで更に別の設問で考えています。→考えてみます。 _________________ OFF企画中ご意見募集 [ メッセージ編集済み 編集者: はにまる 編集日時 2005-02-09 12:47 ] | ||||||||||||||||||||||||
|
投稿日時: 2005-02-09 12:29
objectです。
>ラフィンさん >では、このＷＩＮＤＯＷクラスの例ですと >「右の位置は左の位置プラス幅」というルールは何故に情報側に必要なのでしょうか？ … (1) >・情報：左、右、幅の３つ >・振舞１：移動（方向 as 角度，移動量 as 相対座標） > これにより左と右が変更される。 >・振舞２：サイズ変更（方向 as 角度，変更量 as 長さ） > 方向が左なら左と幅が、方向が右なら右と幅が変更される。 >振舞２には暗に「幅は左と右の距離」というルールがもりこまれていますが、これだと「破綻している」のですね？ … (2) (1)に関してですが、 これは「情報」が強要している訳では無いと思います。 「ＷＩＮＤＯＷクラス」にとって「右の位置」は、所謂「属性＝情報」であり、しかも関係によって決定される関係になっている という事だと思います。 それらの関係をどうするかは、どちらかというと「分析・設計」レベルの問題だと思います。 #しかし、「プロパティ」がないと「関数によって表現される情報」は表現する事すら出来ない。 (2)に関して、 この様な主旨の話をした事は無いと思いますよ？ 私は、 「振舞」では無くて「情報の場合に破綻する」 と言っている訳です。 例えば、ＷＩＮＤＯＷの中心(：Point)を情報としてユーザーに提供する場合、関数を使いますよね？ つまり、 「情報」でも、「関数(演算)で表現される」場合があるから、 関数(演算)は「振舞」 という考え方は破綻していると言っている訳です。 >もう一つ、「これらのルールが振舞にあってはならない」だとしても、「情報になければならない」 >とはならないと思います。例えば情報・振舞以外の別の要素であってもよいはず。 「情報、振舞」は、このカテゴリをベースにすれば、新たな構造(構造が間違っていない限り）を付加し、複雑化する事は当然出来ます。 逆に、もっと単純な形式を考えても、最低限これら「二つの対概念」が必要であるという意味だと思います。 >ＷＩＮＤＯＷクラスのフィールドを２つにするなら、左と右の方がしっくりきませんか？要するにルールは、 >・「右の位置は左の位置プラス幅」 >・「幅は左と右の距離」 >のどっちが適切か？ということなのですが．．． >合理化しようとするとこの手の問題が出てこないですかね？ 上でも少し書きましたが、これは、「分析・設計レベルの問題」だと思います。 どちらが、より実際の状況に合ってるかを判断して決める事だと思います。 また、「プロパティ」で「カプセル化」出来ますから将来的に問題になる事は無いと思います。 私は、もっと基本的な、それ以前の「構造」を問題にしている訳です。 #表現すら出来ないという状況を無くそうと言っている訳です。 私がここで言ってる内容を少し別の表現をしてみます。 E1 、E2 がそれぞれ算法 p、q を持つ代数系である場合、 E1 から E2 への写像 f が f(p(x,y)) = q(f(x),f(y)) … (1) である場合、f は準同型写像といいます。 ここで、p､q が乗法 * の場合 (1) ⇒ f(x * y) = f(x) * f(y) となり、 対応する「要素のカテゴリ」が保たれた状態で、「E1での乗法」が「E2でも乗法」に対応する事が分かります。 分かって頂けたでしょうか？ | ||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.