タグ

modelingに関するtekehikoのブックマーク (22)

  • SOAを超えて: 動的な業務アプリケーションのための新しいエンタープライズアーキテクチャフレームワーク

    ソフトウェア開発においては、多くのフレームワークや製品がその(変化に対する)適応能力を誇示しています。あるソリューションがどれほどうまく変化に適応できるかを把握しようとする前に、システムがどのように変化するか - それこそがダイナミック(動的)と言うことです - についてのしっかりした定義が必要とされます。 初期のオブジェクト指向による手法では[1]、システム分析は中立でなければならず、現実世界に置ける二種類の要求をベースにしていました。: 現実世界のエンティティ?現実世界のエンティティとその関連についての情報を収集することで、技術的・主観的な視点ではなく、オブジェクティブな視点でシステム構造の分析を開始することができる 現実世界のイベント?現実世界のエンティティが持つ状態を変化させるイベントの発生のみが、システムの振る舞いを決定する あらゆるシステム分析に対するこうしたコンテキストにおい

    SOAを超えて: 動的な業務アプリケーションのための新しいエンタープライズアーキテクチャフレームワーク
  • スキーマ不定のデータをRDBに永続化する方法の比較 — ありえるえりあ

    Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ

  • Life is beautiful

    ここのところ「iPhoneアプリUIの大半(ひょっとしたらアプリすべて)をHTML+JavaScript+CSSで作ることはできないか?」に挑戦している私。 そのためにまずは部品作りからとりかかっているのだが、昨日から今日にかけて作ったのは、プログレス・バー、スライダー、トグルスイッチなどの「連続値・不連続値」を表示・入力用UIコントロールをウェブページ上で実現するためのJavaScriptライブラリ。 見た目(Look&Feel)はCSSを使って自由に指定できるように作りつつ、シンプルでありながらいろいろな場面で使い回しがきくライブラリを作りたかったので、何度もリファクタリングを繰り返してしまったが、なんとか形になってきた。 ということで、そのライブラリ(jTouchControl version 0.10)を使ったiPhone風トグルスイッチを公開。一応、Safari (4.0),

    Life is beautiful
  • えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ

    Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために(O/Rマッピングをしているだけ)、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし

    えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
  • Ruby on Railsの「えせMVC」の弊害

    先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC(Model View Controller)がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの(コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること)を避

  • profeth.de

    このドメインを購入する。 profeth.de Privacy Policy | 2018 Copyright. All Rights Reserved.

  • Kodougu - TopPage

    Kodougu とは Kodougu とは、ブラウザ(Firefox/IE)上で動作するモデリングツールです。UML などのモデリング言語を用いたモデリングを、専用ツールをインストールすることなく、ブラウザ上で動作させることができます。また、Kodougu はウェブサイト(ホームページ、ブログ、wiki など)に貼り付けることもできます。 Kodougu の使い方は以下のチュートリアルを参照してください。 Kodougu チュートリアル Kodougu に関するアナウンスは以下の RSS で配信されます。興味のある方は、RSS リーダに以下の RSS を登録してください。 http://www.kodougu.net/p/kodougu/rss ニュース 2008-07-25 14:38 : [メディア掲載情報] InfoQ にて Kodougu の紹介記事が掲載

  • ソフトウェア開発におけるウェブベースのコミュニケーションにモデリングを導入する

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    ソフトウェア開発におけるウェブベースのコミュニケーションにモデリングを導入する
  • 関数従属性は多重度に先行して認識される - 設計者の発言

    「ライド・オン・Rails」を読んで、著者のひとりの馬場さんにメールしたのが縁で「RubyOnRails勉強会@関西」で話をしてきた。業務システムに関わるためには簿記の知識が必須だとか、デーモデリングの基礎知識なんかを漫談風に解説してタダ酒をご馳走になった。 大胆にもRailsの問題もいくつか指摘した。そのひとつが、Railsで利用されるORマッパActiveRecordでは「複合キー」に関数従属する項目の存在を認めていない点だ。そのような業務要件を含むデータベースをRailsでは扱いにくい。 たとえば、「契約単価」は「顧客コード」と「商品コード」との組み合わせに、「月次TTMレート」は「通貨コード」と「年月」との組み合わせに関数従属する。こういう関係は業務システムではふつうに存在する。Rails格的な業務システムを扱うためのフレームワークではないのだからいいじゃないかと考える向きもあ

    関数従属性は多重度に先行して認識される - 設計者の発言
  • Amazon.co.jp: MDAモデル駆動アーキテクチャ: David S.Frankel, 日本アイ・ビー・エム TEC-J MDA分科会: 本

    Amazon.co.jp: MDAモデル駆動アーキテクチャ: David S.Frankel, 日本アイ・ビー・エム TEC-J MDA分科会: 本
  • 汎用言語とドメイン特化言語を組み合わせたモデルドリブンエンジニアリング

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    汎用言語とドメイン特化言語を組み合わせたモデルドリブンエンジニアリング
  • 『ドメインロジックの実装方法とドメイン駆動設計』

    以前一緒にお仕事をさせていただいたこともある、ビープラウドの佐藤治夫さんが主催の勉強会BPStudy 第7回にて、発表の機会をいただいたので話してきました。発表テーマは「ドメインロジックの実装方法とドメイン駆動設計」です。 http://www.beproud.jp/bpstudy/17/bp-study-7 後ほどBPStudy勉強会のサイトでも発表資料が公開されると思いますが、こちらにもUPしておきます。(アメブロではSlideShareやhandsOutのスライドを直接貼れないようなので、ちょっと変な貼り方をしています) http://handsout.jp/slide/371 以下の二部構成でお話ししました。Ⅰ. ドメインロジックの実装方法 Ⅱ. ドメイン駆動設計の紹介 前半は、お馴染みの「トランザクションスクリプト vs. ドメインモデル」の話です。それぞれのサンプルコードを交え

  • 第21回 流れる情報と留まる情報 | WIRED VISION

    第21回 流れる情報と留まる情報 2008年3月26日 IT コメント: トラックバック (0) (これまでの増井俊之の「界面潮流」はこちら) 世の中の様々な情報は、いつでも参照できるストック型情報と、リアルタイムに流れてくるフロー型情報におおまかに分類することができます。最新のニュースや天気予報は重要ですが、古い情報はあまり役にたちませんからもっぱらフロー情報として扱うのが適切ですし、百科事典や辞書などはストック情報として扱うのが適切です。しかし、新しくてかつ保存が必要な重要な情報の場合、両タイプの取り扱いが必要になるので取り扱いが面倒になります。 ■ストック情報とフロー情報の変換 ストック情報とフロー情報はあらゆる場面で常に変換が行なわれています。聞いた話をメモ帳に書くという行為はフロー情報のストック化ということになりますし、手帳からネタを捜してブログを書いている人はストック情報をフロ

    tekehiko
    tekehiko 2008/03/27
    『将来的にはフロー情報とストック情報をうまく併用できる新しいコミュニケーション手段が欲しいところ』
  • 『DDDについての覚書』

    少し前のことだが、.Net Rocks! というオンライントークショーのサイトに『Domain-Driven Design』の著者Eric Evansのインタビューが上がっていたので、今になってiPodに入れて通勤の行き帰りに聴いている。 http://www.dotnetrocks.com/default.aspx?showNum=236 インタビューの中で非常に印象的だったポイントを2つ、覚書として書いておきたい。 - DDDだからといって、全部ドメインモデルで構築するものだと思い込むのは間違い - 重要なのは、開発手法としてのアジャイルではなくて、ビジネス来のアジャイルさ(変化のスピード)についていくこと Martin Fowler, Eric EvansDomain-Driven Design: Tackling Complexity in the Heart of Softwa

    tekehiko
    tekehiko 2008/03/24
    『重要なのは「フォーカス」であって、アプリケーション全体を精密にモデリングしようとするのは、よくある間違い。ビジネスにとって最も価値のある部分に全力を投入して、そこだけはリッチにドメインモデリング』
  • 業務アプリには関数と構造体だけあればいい件について - yojikのlog

    たけぞうさんやひがさんの古いエントリをよんでいまさら考えてみました。 http://www3.vis.ne.jp/~asaki/p_diary/diary.cgi?Date=20070128#2007012800 http://d.hatena.ne.jp/higayasuo/20070129#1170052662 関数と構造体しか無い、いわゆる構造化設計*1だと、上位の関数が下位の関数に処理を委譲して・・・みたいな感じで、機能のツリー構造が出来上がる。このような構造では必然的に、上位レベルの関数が下位レベルの関数(のインタフェース)に依存することになると思う。上位の関数が、下位の関数の面倒見る*2から。(追記: 厳密には関数を持つモジュールのツリー構造が出来あがる) ならば下位の関数のインタフェースをカッチリ決めれ! といわれそうですが、なんだかんだで下位の関数こそ変更されやすいのが業務

    業務アプリには関数と構造体だけあればいい件について - yojikのlog
  • 2007-01-29

    デブサミ-VisualBasic, Delphiから10分でJava+Flex2にポーティング http://d.hatena.ne.jp/higayasuo/20070118#1169099987 Flex2では、モデルとUIコンポーネントと間の自動バインディングがサポートされています。自動バインディングとは、モデルの値が更新されたら自動的にUIコンポーネントの表示が更新されたり、UIコンポーネントに入力している値が変わったら、自動的にモデルの値を更新する機能です。 デフォルトではバインディングは単方向です。基的には、モデルの変更をUIコンポーネントが検知するだけ。例えば、次のようなMXMLがあったとします。 <?xml version="1.0" encoding="utf-8"?> <![CDATA[ [Bindable] private var hoge:String; ]]>

    2007-01-29
  • Analysis Pattern: Snapshot

    tekehiko
    tekehiko 2008/03/24
    ある時点におけるビューを提供するためのパターン。
  • 『ドメインモデルに対する日米の温度差』

    マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日ではTransaction Scriptが優勢 この2通りのうち、日ではTransaction Scriptパターンの方が優勢だ。日のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ

    『ドメインモデルに対する日米の温度差』
  • Eric EvansがDDD(ドメイン駆動設計)を語る

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    tekehiko
    tekehiko 2008/03/23
    『まずはソフトウェアの対象となるビジネスやドメインについてもっと熟考し、そのあとでソフトウェアの開発に使用するテクノロジーやすべての手法、さらにはプロセスについて考える必要がある』
  • ドメインロジックとSQL

    以下の文章は、Martin Fowler による Domain Logic and SQL の日語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの(rich SQL queries)を用いるので悪しからず。 エンタープライズアプリケーション(訳注:以下、EA)構築に関する(私の近著『P of EAA』など)を読むと、ロジッ