「ドメイン駆動設計」を読み直すようになってから、UMLによるモデリングをもう一度見直している。 アイデアをラフなメモ書き。 【参考】 オブジェクト指向設計の4つの流派からドメイン駆動設計へ: プログラマの思索 astah* professional 6.1の要求図: プログラマの思索 SysMLの要求図の書き方: プログラマの思索 シーケンス図とアクティビティ図と状態遷移図の関係: プログラマの思索 FP法で業務モデルを計測する: プログラマの思索 【1】僕は、UMLの各種ダイアグラムを、業務やプロセスやシステムの分析のラフなスケッチに使っている。 業務の流れ、プロセスの流れ、システムの振る舞い、システムの機能の関係を理解したい時、絵を描く方が、理解が早まる。 基本は手書きが多い。 でも、astahで描いておくと、後から何度でも修正変更できるし、ブラッシュアップできる。 UMLの利点は、1
astahにタイミング図がサポートされたのでメモ。 【参考】 astah* 9.2リリースノート | astah タイミング図 | astah* 機能ガイド plantumlでタイミング図が描けるらしい: プログラマの思索 astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い: プログラマの思索 astah* Mermaid Pluginが公開された: プログラマの思索 Timing図 わかりやすくUMLタイミング図とは 【PlantUMLの使い方】PlantUMLでタイミングチャートを作成する - システムとモデリング UMLのタイミング図を使う機会は正直ほとんどないし、経験もない。 感覚的には、シーケンス図を横型にしたイメージを持っている。 ただ、ハードウェア設計者ならタイミング図をよく使うと聞いているので、どんな状況でどのように使うのか、調べ
MVC2モデルとMVCモデルの違いについて、良い記事があったのでリンクしておく。 【元ネタ】 MVCをWebに適用した「MVCモデル2」 : Java好き MVCモデルのバリエーション: プログラマの思索 (引用開始) 「MVC」と「モデル2」の違いが、「モデル」の設計に影響を与える 違いは、「モデル」が「ビュー」に状態が変わったことを通知することがWebの性質上なくなった点。 サーバー側からいきなり「モデル」の状態変更が通知されることは HTTPではできないので、必然的にそうなる。 大したことのない変化に思えるが、これにともない「モデル」の構成が「MVC」と大きく変わる。 「モデル」が状態が変わったことを通知することができないことは、 毎回最新の状態のモデルを作ることにつながる。 「MVC」では前状態を保持しつつ状態変化に対応させるといった「モデル」の使い回しが可能だった。 しかし、「モ
かつての古き良き時代、右肩上がりの高度成長の頃は、なにごとも単純明快で分かりやすかった。製造業は、生産量を上げることにひたすら邁進した。「作れば売れる」時代だったからだ。昭和40年代や50年代の日本企業の多くは、欧米先進国から技術を導入しつつ、自分でもそれを改良し、使いこなしていった。その時の工場運営でキーとなる指標が、機械の稼働率だ。 たとえば、あなたの会社が3億円の大枚をはたいて、海外から高価な製造機械を導入したとしよう。15年間の寿命を想定すれば、減価償却費は毎年2千万円だ。それでも、旧式の機械+手作業に比べれば数倍以上の生産能力を上げられるし、より高品位な製品も作れる。だからソロバン勘定に合うはず、と考えて導入に踏み切るわけだ。 当然ながら、社長は工場長に対して、この機械を最大限活用しろ、とハッパをかける。機械は動いていても止まっていても、同じ減価償却費がかかる。だとしたら動かさな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く