tm-versions
TM （Ｔ字形 ER手法の改良版） は、実地の使用のなかで験証を続けて、かつ、数学・ロジック （論理学）・哲学の観点から検証を続けているので、改良を施してきています。そのために、現時点での体系 （最新の体系） を知りたいという要望が多いので、本 ホームページ で、TM の最新 バージョン を記すことにしました。TM を見直した折りに、そのつど、新しい バージョン を示していきます。 ● TM3.0 （2022-07-22） → 「モデル 作成技術 TM 入門」 （技術評論社） ● TM3.0 の元資料 （2020-12-30） → TM3.0 の技術 （説明資料 ダウンロード） ● TM2.0 （2015-06-04） → TM2.0 の基本的な考えかた （説明資料 ダウンロード） → TM2.0 の技術 （説明資料 ダウンロード） ● TM1.0 （2009-01-23） 「赤本」 「い
データモデリング | ローコード開発基盤 楽々Framework3
データモデリングとは データモデリングとは、ある方法論に従ってデータを構造化していくことであり、広義にはリレーショナル・データベースだけでなく、あらゆるデータソース(文書ファイル、ハイパーテキスト、オブジェクトデータ等)と関連付けの方法による構造化が対象となりますが、狭義にはリレーショナル・データベースの関係モデル(関数従属性)を使って事業のデータ構造を表すことです。ここでは特に断らない限り狭義の意味で用いることとします。 かつて、データ構造がアプリケーションの都合により左右される時代もありましたが、データモデリングの普及により、データがアプリケーションから独立していることが重視されるようになりました。いわゆるDOA(Data Oriented Approach)です。近年、オブジェクト指向、アジャイルソフトウェア開発、クラウド、ビッグデータ、NoSQL、IoTなど様々なアプリケーション開
イミュータブルデータモデル(入門編)
6. Step1 エンティティの抽出 発送担当者が受注リストをもとに、商品の在庫を確認し、在庫が あれば商品を発送する。 ① 要求仕様の「動詞」を抜き出しエンティティとする。 ② ①に関わる「名詞」を抜き出しエンティティとする。 ③ エンティティ間の関連に線を引く ④ 属性や候補キーも分かる範囲で書いておきます。 間違い！ この段階で実装をプロパティファイルにするとか、Enum にするとか決め打ちでエンティティとして表さないのはや めましょう。 まず、はじめにエンティティを抽出します。
イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか
図１．シンプルなスクラム構成 この最小限のフレームワークの中で、チームのインプットとなるのが”ユーザ要求”としての”プロダクトバックログ”です。そして、アウ トプットは”動くソフト ウェア”としてのコード（”製品コード”と”テストコード”）です。 そこには他の設計要素が明示的に現れてはいません。スプリントの中で作られたすべての意図的な設計はチームの財産として実行コートの中に組み込まれるのが 望ましいですが、そこには直接コード化されない情報もあります。スクラムは開発プロセスであり、設計に関しては敢えて何も言及していませんが、設計と設 計活動はチーム内部であいかわらず行われています。 Grady Booch氏は”コー ドは真実ではあるが、すべての事実ではない” と語っています。だから、もしそこにコードで表現又は伝われない情報が残されるとしたら、私達はその情報をどこに格納できるでしょうか？その質
概念モデルと論理モデルの違い（前編） - 設計者の発言
管理会計システムの開発ツール「FusionPlace」の開発者であり会計士でもある杉本さんが、９月の「第19回関西IT勉強宴会」でたいへん興味深い発表をされた。それを聞いて、私の中で曖昧だった「概念データモデル」の位置づけがはっきりして、「論理データモデル」との違いが浮き彫りになった。この快適なスッキリ感をおすそわけしたい。 ■従来の「概念データモデル」の危うさ これまで「概念データモデル」という用語は「対象領域における重要なテーブルのみを示したデータモデル」くらいの意味で使われていた。１ページか２ページに収まるように重要なテーブルのみを置き、しばしばキーが省略された形で示される。一部を示すとたとえばこんな調子だ。 以前に書いた記事「危ういデータモデルを見破るコツ」で、概念データモデルと呼ばれる図面の上に「多対多」のテーブル関連が現れることを批判した。一部のテーブルを省略すれば必然的に「多
データモデリングなきアジャイル開発は危ういか？：An Agile Way：オルタナティブ・ブログ
尊敬するDOAの先輩である、渡辺さんがこう書いている。 「データモデルなきアジャイル」の危うさ、より その種のシステム（※引用者補記：販売管理システムや生産管理システムといった基幹系業務支援システム）をアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 それに対して、稲見さんがこんなコメントをしている。 アジャイル開発と言っても色々で、最近流行りのScrumという手法は、開発の中身に関しては何も言及していません。ですが、私の知っているある人達
Value Object の設計 - Aufheben - GLAD!! の日記
まずは、設計・実装における Value Object を整理した方が良さそうなのでまとめてみました。 Value Object の設計方法としては、以下の3通りがあると認識しています。 # 仕事で主に使用してきた言語が C++ と Java なので、もし他にもあればご教示ください。 1. Singleton インスタンスを1つしか生成しないパターンです。 Java の enum がこれに該当します。 同一性は == で判定することができます。 2. 不変オブジェクト インスタンスが1度生成されたら、属性の変更を許可しないパターンです。 Java のプリミティブ型のラッパークラス(Integer など)、String、BigDecimal などが該当します。 Java の場合、hash と equals メソッドをオーバライドする必要があります。 3. スコープ外へ公開する際に複製する クラ
Multi-Paradigm Design : Introduction (Japanese)
Multi-Paradigm Design 『マルチパラダイムデザイン』への序論 James O. Coplien PhD thesis, Vrije Universiteit Brussel, May 2000, pp. 13 - 22 日本語 第1版 2002年2月2日 これは，Multi-Paradigm Design. PhD thesis, Vrije Universiteit Brussel, May 2000.の"Introduction"を日本語訳したものです． マルチパラダイムデザインは，１つのテクノロジやテクニックを越えて，ソフトウェアにおける抽象および設計についての基礎的な疑問を，より深く掘り起こそうというものである．パラダイムとは何なのか，分析・設計・実装にはどのような関係があるのかといった質問により，「抽象」というものの基礎が形作られる．ここで，「抽象」とは，設
連載：次世代開発基盤技術“Software Factories”詳解 第3回 長期的な要求を定義するフィーチャ・モデル（1/2） - ＠IT
フィーチャは非機能要求を含むアーキテクチャの要求と再利用可能な機能を提供し、ユースケースはアクター（＝エンドユーザー）に対する機能を提供する。Software Factoriesでは、プロダクトライン・アーキテクチャの提供するフィーチャを取捨選択することで、アクターの要求に応じたユースケースの追加、更新に対応する（例えば、「カタログ検索」のユースケースでは、「カタログ管理」のフィーチャを選択することで、その機能が追加される）。要するに、フィーチャはアーキテクチャとして提供される長期的要求に対する機能を、ユースケースは一度限りの開発プロジェクトの短期的要求に対する機能を提供するのである。 ●書籍購入サイトにおけるフィーチャとは？ 例に取り上げた書籍購入サイトでは、表の横軸にあるような「カタログ管理」「注文処理」「課金処理」「認証」、さらには「データ分析」「出版会社や卸との取引管理」「営業支援
クラウド対応のモデリング技術がおもしろくなるかもしれない - きしだのはてな
いま、大きいのはクラウドから小さいのはGPGPUまで、並行システムはなざかりです。 クラウドなど、並行システムが不可欠となったとき、並行システムのモデリング技法が必要になります。 でも並行システムを作るために使えるモデリング技法で、現場の技術者に定着したものはありません。 いま現場で使えるのは、オブジェクト指向モデリングです。 オブジェクト指向のモデリングではUMLを使うと思うのですが、UMLを使ったオブジェクト指向のモデリングでは、クラス図・オブジェクト図が静的な関係を表し、シーケンス図・コラボレーション図はシングルスレッドでのフローをあらわします。これらの図は静的な関係か、シングルスレッドをあらわします。 複数スレッドを扱えるのはアクティビティ図ですが、ここではスレッドの同期を扱えるだけです。 UMLでは、動的な関係の遷移を表すことができません。 並行システムを考えるときには、動的な関
ドメイン駆動設計の概要
目次 プラトン的モデル 言うべきことを言う コンテキスト 価値提案を把握する 単一責任システム エンティティは ID とライフサイクルを持つ 値オブジェクトは記述する 集計ルートによりエンティティを結合する ドメイン サービス モデルの主要な操作 リポジトリにより集計ルートを省略する データベースの関連事項 DDD の使用を開始する ドメイン駆動設計 (DDD) とは、洗練されたオブジェクト システムの設計に役立つ原則とパターンをまとめたものです。設計に DDD を適切に適用することで、ドメイン モデルと呼ばれるソフトウェア抽象化を実現できます。このモデルにより複雑なビジネス ロジックをカプセル化できるため、実際の業務とコードとの間に存在するギャップを小さくすることができます。 この記事では、DDD に関連する基本的な概念と設計パターンについて解説します。機能豊富なドメイン モデルを設計し
Home Page
Welcome To LuRuJu Site LuRuJuとは、UMLモデリングツールJUDEのモデルデータをオブジェクト指向スクリプト言語Rubyで操作する為のライブラリです。 また、JUDEとWebフレームワークRuby on Railsとのダイナミックな連携を実現したLuRuJu on Rails（Railsプラグイン）も提供しています。 LuRuJuライブラリ及び本サイトは、ともにフリーエンジニアである野村周平（通称ばんちょー）が趣味で細々と作成しています。 現段階ではまだまだ未完成ですが、公開し皆様の意見をフィードバックしながらライブラリを育てていこうと考えています。 本ライブラリを使って頂いた方がほんの少しでもハッピーになれればこの上ない喜びです。 What’s New 2008-4-05 RubyForgeにLuRuJuのパッケージを登録しました 2008-3-21 LuRu
REAとビジネスパターン入門(1)
コンサルティング業の片手間に，翻訳業をしている。ここしばらく作品がなかったのだが，今月（2007年8月）は2冊の監修・監訳作業を終えることが出来た。1冊は，まもなく発売される予定の『実践UML 第3版』。もう一冊は，日経BPソフトプレス発行の『ビジネスパターンによるモデル駆動設計』（以下，『モデル駆動設計』と呼ぶ）である。 『モデル駆動設計』のほうが，ちょうど書店に並び始めたので，今回は，そこに登場するREAという概念と，モデル駆動設計の方法について紹介してみたい。翻訳作業が終わって1カ月あまりになるが，この原稿の準備をするなかで，あらためてわかったこの書籍のおもしろみや，類書との類似点や相違点についても触れてみたい。 REAとは何か 『モデル駆動設計』の副題は「REAによる新しいモデリング手法」である。REAとは，リソース（Resource)，イベント（Event），エージェント（Age
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
八角研究所 : Ruby on Rails によるシステム開発をモデリングで効率的に行う（3） - 分析・設計編（フィーチャモデリング）
REA Technology - Technology That Understands Your Business