タグ

modelingに関するyuguiのブックマーク (42)

  • オンラインでVisioのような図表が描ける「Gliffy」 - ネタフル

    Make diagrams online with Gliffyというエントリーより。 Web site Gliffy is a free web-based diagramming tool along the lines of Microsoft Visio. Lifehackerで、オンラインでVisioのような図表が作成できる「Gliffy」が紹介されていました。 Whether you’re creating flow charts, floor plans, or pretty much anything you’d consider a diagram, Gliffy actually looks like it can handle it. フローチャート、フロアプランなどのダイアグラム(図表)の作成が可能です。また全ての作業を記録していれる機能も搭載しているということです

    オンラインでVisioのような図表が描ける「Gliffy」 - ネタフル
  • L'eclat des jours(2006-06-26)

    _ まとめ 良くわからなくなったのでまとめてみた。わかる粒度が名前を知ってるだけ、概念を理解している、実際に利用したまでばらけているので、嘘八百のような気もする(というか、嘘は確実にある)。 こういうときにマインドマップってのを使うんだろうか? EA(全体統合) BA …… プロセス DA …… データ AA …… 制約 TA …… 実装 DOA(AS IS重視)—フラット—物理モデル—ボトムアップ まずモノ(エンティティとリレーション) 検証手段:エンティティの整合性 思考法:join 抽象的  T字型派……純粋抽象派(ここに含めるべきではないのでは) ↑   伝統派……業務分析 ↓   TH派……帳票上のエンティティ 具象的  はぶ派……UI(Webのページ、帳票など)上のエンティティ+業務フロー (頂いたコメントを元に修正:7/1) 伝統派……業務分析 TH派……帳票上のエンティティ

  • 考えさせられる - yojikのlog

    RubyKaigi2006 RESTのPOST,GET,PUT,DELETEとDB(というかリソース)のCRUDの類似。Webアプリケーションにおける殆どの操作は、リソースのCRUDに対応させることができる。*1 実際のアプリのレベルに落として考えると、例えばユーザをグループに追加する際に、ユーザコントローラに対して「グループに加入させよ」メッセージを送る*2のではなく、メンバシップコントローラに、ユーザ-グループ間のメンバシップをCREATE(REST的にはPOSTで依頼)してもらう事になる。*3。 上記を徹底すればWeb(アプリ|サービス)が、外部からDBのように扱えるようになる。多分、この話がActiveResourceに繋がる。(のだと思う) なんか学ぶべき点が多そうです。 あと個人的には、DBのように扱うためには、ユーザ(や他のアプリ)との対話の中で、適切な単位でCRUDを纏め上

    考えさせられる - yojikのlog
  • 複雑さに金が落ちる時代は本当に終わるのか? - アンカテ

    RailsやChuraのいけてないところ これは、Ruby on Railsに対する実に的確な批判だと思う。だが、これによって逆にRailsの意味が見えてきたような気がする。 (このエントリ、入口はソフトのやや専門的な話ですが、例によって大風呂敷で、そこから"The World is Flat"の話につながっていくので、できればプログラマ以外の方もおつきあい下さい) Railsというソフト開発ツールの良さは、単に便利とかフルスタック(必要な全ての機能盛合せ)ということではなく、実践的な仕事の流れが背後に想定されていることだ。頭をひねってツールを使いこなすというより、ツール(が想定しているソフト開発手順)に「乗る」という感覚で開発を進めることができる(まさに On Rails)。 だから、Railsの個々の機能の過不足を問題にするのはあまり意味が無い。仮に不足があったとしても、オープンソース

    複雑さに金が落ちる時代は本当に終わるのか? - アンカテ
    yugui
    yugui 2006/06/22
    はぶさんの提起する問題への素晴らしい分析。「向上しているとは言っても、私が今持っている「業務」のレベルの複雑さに対応できるものではない。ただ」。そうか、ABDはその直感的分析が通用する上限を押し広げるんだ
  • http://capsctrl.que.jp/kdmsnr/diary/20060620.html

  • RailsとABDとCRUDとワークフロー - moroの日記

    羽生さんのABD(Activity Based Datamodel)ですが、それを知った感想を自分なりにすごく乱暴にまとめると、DBをイベント系とリソース系にわけた上で、仕事っていうのはリソース間やイベントとリソースの間になんらかの関係を発生させる捉える、という考え方かなぁ、と。 イベントとリソース 売上げが立つ、というイベントはつまりお客さん(リソース)と商品(リソース)との間に購入/入金という関連が発生するというふうに捉えられます、と。 あんまり例えが良くありませんが、ビジネス上のできごと=イベントに着目し、イベントも関連テーブルのエンティティを素直にcreateすることで表現するという方法論だと読んでいます。 さらにDBを設計するということは、そういったイベント、すなわちビジネス上のアクティビティをどう記録するか、という観点でデータの持ちかたを設計していくということなんじゃないでしょ

    RailsとABDとCRUDとワークフロー - moroの日記
  • 6月のはぶにっき

    not found

    yugui
    yugui 2006/06/17
    Railsの開発法はDOAではないかという批判。「そもそも画面にあわせてDBを持てばいいっていうなら、もっと優れた方式があるじゃん。そうです、Tuigwaaですよ。」。そこで、acts_as_abd(仮)ですよ。
  • [結] 2006年6月 - 結城浩の日記:モノクロ画像がカラーに見える錯視

    目次 2006年6月25日 - 長男と完全数談義 / 2006年6月23日 - ティナからの手紙 / 2006年6月20日 - 無神論者との対話 / 2006年6月18日 - 父の日 / 2006年6月16日 - ソフトウェアは、私たちの想像よりもずっと複雑 / 2006年6月14日 - 仕事 / 2006年6月13日 - 無限羽の鳩と無限個の巣 / 仕事 / Haskell / 読書 / 2006年6月12日 - 仕事 / 2006年6月10日 - モノクロ画像がカラーに見える錯視 / 日記ダイジェストを更新 / 2006年6月8日 - www.textfile.orgのお引っ越し / 2006年6月5日 - 仕事 / 2006年6月4日 - 今日の一日 / 2006年6月3日 - 誤植 / 2006年6月1日 - 仕事 / ぜひ、感想をお送りください 日記一覧 2006年6月25日 ■

    yugui
    yugui 2006/06/17
    「テストのないコードの信頼性が低いように、コードのない設計の信頼性は低いのではないか」
  • EJB3時代のアーキテクチャパターン 業務ロジックType5について - t-wada の日記(旧)

    id:higayasuo:20060615#1150364455 ひがさんが説明しているType5のやりかたが、今の案件で行っている方法にえらく似ているのに驚きました。考えていることが似ていたのかな。私のところではMayaa+無設定S2Struts+S2Daoを使っているのですが、HTMLとMayaaとERD(から生成したファイル)を生成の入力ファイルとして使い、Service実装以外のクラスを全部自動生成しています。生成するクラス群はGoyaのレイヤモデルを採用しています。 開発していくときに実際に書くのは、生成されたServiceのサブクラス(Generation Gapパターンでやってます)と、自動生成では生成できない複雑なSQLを呼ぶためのDaoと、そのSQLファイルです。他のレイヤのクラスおよびインターフェイスは自動生成したものを使います。自動生成のためにMaven2のプラグイン

    EJB3時代のアーキテクチャパターン 業務ロジックType5について - t-wada の日記(旧)
  • 【レポート】Developer Summit 2006 - DBは超グローバル変数、どう設計するか | エンタープライズ | マイコミジャーナル

    稿では、2月9日に目黒雅叙園で開催された翔泳社主催のカンファレンス「Developers Summit 2006」から、スターロジック代表取締役兼CEO 羽生章洋氏のセッション「楽々ERDレッスン〜これが楽々DB設計の勘所!〜」の模様をレポートしたい。なお、羽生氏は、Seasarファウンデーションの理事を務めるなど、オープンソースソフトウェア開発コミュニティでも活躍中である。 さて、システム開発の現場において、データベースの設計は特に重要視されることが多い。では何故DB設計が重要なのか、という問いに対し、羽生氏は「DBはアプリケーションをまたがる『超グローバル変数』だから」だと語る。個別のプログラムにおいてさえグローバル変数の使用には注意が必要なのだから、時として複数のシステムに影響を及ぼすデータベースの設計に最大限の注意が必要なのは当然、というわけだ。データベースの設計がいい加減だと、

    yugui
    yugui 2006/06/15
    はぶさん
  • 『社員マスタという不思議なエンティティ(第2回)』

    このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日のドメイン登録業者(レジストラ)(「ICANNがレジストラとして認定した企業」一覧(InterNIC提供)内に「Japan」の記載があるもの)を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。

  • O/Rマッパーの新しい形? - Hydrate 2.0 | エンタープライズ | マイコミジャーナル

    Hydrate 2.0 リリース The Hydrate Projectは4日(米国時間)、Hydrateの最新版であるHydrate 2.0を公開した。HydrateはJavaで作成されたデータ変換用ツール。RDBMS、XML、オブジェクト指向言語という3つの異なるデータを相互にシームレスに変換する操作を実現する。 RDBMS、XML、オブジェクト指向言語という3つの異なるデータは、UMLというデータ形式でニュートラルに表現することができる。HydrateはそれぞれのデータをUMLでモデリングするためのツールのようにもみえる。 図1 オブジェクトモデルおよびXML Schema定義の可視化ビュー 図2 可視化ビューで使われているクエリの編集画面 Hydrate 2.0はGNU LESSER GENERAL PUBLIC LICENSE Version 2.1のもとで公開されているオープン

  • システムの寿命はコードで決まる!(1/3) ― @IT

    コードはシステムの寿命に大きな影響を与えます。今回は、コードとデータベースエンジニアの関係を通してこのことを解説します。ここでいうコードとは、顧客ID、受注伝票番号など、業務上利用されるデータを識別・分類するため、各データの来の名前とは別に割り当てられる記号のことです。 データベースエンジニアにはデータ設計とデータベース設計の2つの役割があります。そして、データベースエンジニアにはデータ設計の一環として安定したコード体系を設計し、データベースをコード体系に依存しないように設計することが求められます。 システムを長く使い続けるためには、 コード体系を長期にわたり変更せず利用できるようにすること コード体系とデータベース設計との結合度を小さくすること が重要です。なぜなら、コードのけたが足りなくなったり、コードの分類が業務にそぐわなくなったりして、コード体系の見直しを行うことになると、業務・

    システムの寿命はコードで決まる!(1/3) ― @IT
  • http://d.hatena.ne.jp/habuakihiro/20060606

    yugui
    yugui 2006/06/06
    「リソース系には状態遷移があります」「イベント系はワークフローがあります」
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • 「科目履修管理」のレファレンスモデルが登場 - 設計者の発言

    教育関係者に朗報である。四年制大学向けの履修管理システムの基設計情報「CONCEPTWARE/科目履修管理」が、この夏に公開される。同時期に出版する(システム設計の練習用問題集みたいなもの)で扱われている業務要件にもとづく連動企画である。3年前に書いた「上流工程入門」では、基設計書の一部を図版として示すだけだったが、今回は無償のモデリングツール「XEAD」で閲覧・編集できる設計コンテンツとして誰でもダウンロードできるようになる。大進歩である。 システムの規模としては、テーブル数20、機能単位数40程度と小さめだ。「CONCEPTWARE/財務管理」のテーブル数80、機能単位数270と比べると、その小ささがよくわかる。しかも、「財務管理」は簿記の知識がない人にはチンプンカンプンだろうが、「科目履修管理」は業務としてわかりやすい(かといって単純すぎるわけではない)。 そのには「科目履修

    「科目履修管理」のレファレンスモデルが登場 - 設計者の発言
  • ユーザーと共通理解できる“システム観”が必要だ - @IT情報マネジメント

    企業システム開発では、しばしばユーザーの思いどおりのシステムに仕上がらないことがある。その大きな原因の1つが、ユーザーの“要求”と開発者の“理解”のズレだ。ユーザーと開発者が共通認識にたどり着くには、何が必要だろうか?(→記事要約<Page2>へ) 業務システム向けの分析設計技法としてさまざまなやり方が提唱されています。有名なところがUMLを用いた「オブジェクト指向分析・設計手法」です。しかし、開発現場で実際に利用されているのは、昔から無批判に繰り返されてきた古めかしいやり方だったり、せいぜい「UMLもどき」とでもいえそうな案件ごと独自に「工夫」されたやり方です。 UMLは、バラバラだったオブジェクト指向系の表記法を統一するための体系として鳴り物入りで登場しましたが、必ずしも当初の期待どおりの効果を挙げているわけではありません。それは、システム開発においてボトルネックになっているのが「シス

  • 中里一日記: DELETEと参照

    DELETEと参照 Houndを通じてかれこれ1年以上、RDB(PostgreSQL)とORM(Cayenne)につきあってきた。そろそろ、この世界の味がわかってきたので、書きとめておく。 結論:DELETEは深遠な哲学的問題だ。 題に入る前に、RDBの濫用について片付けておこう。 RDBは、あらゆるコンピュータ技術のなかで、もっとも濫用されている。積もりに積もった装飾をはぎとってみれば、RDBというシロモノは、ある面で比類なく優れているかわりに、それ以外の面では恐ろしく融通がきかない。オブジェクト指向がミニバンだとしたら、RDBはF1マシンだ。装飾に隠されてはいるが、質は変えられない。このことを忘れて設計した人々は、あとで莫大な額のツケを請求される(こうしてOracleが儲かるわけだ)。 手始めに、行ロックを退けよう。トランザクションを開始するときには、トランザクションを終了するまで

  • 二人の借金になるのでしょうか?結婚前の借金でもめています | 【貴方のお役に立ちます!】優良消費者金融紹介サイト佐賀県版!

    32歳の働く主婦です。一年前に10年間同棲していた彼と結婚しました。彼に借金があることを今まで知らなくて、お金がないから結婚式も挙げられない、新婚旅行は近場の観光地で宿泊だけでした。彼は子供ができたら大きい車が必要になるとか言って、結婚後に車のローンもはじめました。それなのに借金があったなんて!結婚したら二人の借金になるんでしょうか?私は買いたいものを我慢して自分の給料を生活費として家に入れているので、とても腹立たしい気分です。 結婚すると良いことも悪いこともすべて二人のものになります それはかなり腹が立ちますね。というか裏切られた気分じゃないですか?名義がご主人ならば彼の借金なのですが、二人で生活しているわけですから二人の借金と捉えるのが一般的かも知れません。 せめて結婚前に借金があることは教えて欲しいですよね。女性は結婚式できれいなドレスを着たり周囲に祝福されたりしたいわけだし。それな

  • OBB vs AABB - Radium Software Development

    iPhoneの一般修理店は予約なしでも来店できる? 基的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、