T字形ＥＲ図の基礎知識
知識１ リソースとイベントの分け方 イベントとリソースを分けているのは「〜する」という言葉を付けて成り立つかどうかです。 つまり「受注＋する」は言葉として成り立つのでイベント。しかし「商品＋する」は成り立たないのでリソース。 他には、「イベントには年月日などのタイムスタンプが含まれるが、リソースには含まれない」という見方で切り分けても良いです。 これによって細分化されたリソースは、リソースの中にリソースが含まれることはなく、独立した存在となります。 リソースとリソースとの関係表現には、必ず「対照表」というものが使われます。 つまり[従業員]というリソースに、[所属部門]というリソースが含まれることはなく、[従業員:部門 対照表]によって「配属」が表現され、組織構造が変わった場合や人事異動の場合にも、この対照表だけをメンテナンスすることで、[従業員][部門]ともに安定した（Sta
Dayanのブログ 業務アプリとオブジェクト指向について
小職は、SE（システムエンジニア）を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。よろしくお願いします。 何度か、独断的なオブジェクト指向論を述べてきたが、ここで少しまとめておこうと思う。 まず第一に、個人的には、オブジェクト指向は好きだし、構造化分析よりも優れていると思う。それは構造化言語よりも多くのことができるからである。世間で勘違いされているような「飛躍的に」まで生産性が高まるとは思わない。また、オブジェクト指向が難解でマスターするのが難しいとも思わない。 難しいと思われている理由は、一つには旧来の手法から移行することが難しいということがあるが、実際には期待したほど生産性が高まらず、原因はきちんと使いこなしていないからだと思い込んでいるためだと思う。これはオブジェクト指向やデザインパターンを魔法のように勘違いしているためだ。
ＤＯＡだとだめで、ＵＭＬを使う場合と、その危険性を洋服ダンスで説明する - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 前にここに書いた話、つまり、 ・はじめにフレームワークと共通部品をつくって ・要求仕様のできに応じて、おおまかな部品をどんどんつくっていき ・仕様ができたときには、繋いでテスト というやり方をとらざるを得ないという話、 じゃあ、現実には、どうなのっていうはなしと、前に書いたブログのプロパティを入れる形のどこがいいのか？っていう話については、また今度、別の機会に書きますとかきました。今日は、現実的な話をみてみましょう。 といっても、ウィリアムのいたずらがかかわった話をかくと、やばいので、 世の中に出回っているはなし、 浮き彫りになったEA導入の功罪 (1/2) http://www.itmedia.co.jp/enterprise/articles/0608/10/news004.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
