The Concept of Model: Definitions and Types (If you wonder at some wording, please consult the tentative translation key) Difficulties with the definition of model Each definition of „model” is insufficient: It covers only a small range of the reach of use. In particular all definitions with the terms „original”, „reality” and „representation” cannot convince. The German “Brockhaus” (1971) offers
東京都立中央図書館(東京都港区)にて企画展示「東京の鉄道史-鉄道が築いた都市、東京-」が開催中だ。東京の地下鉄を再現した3次元模型同企画の目玉展示の1つが「東京動脈」。 東京動脈とは、2007年に東京大学大学院に所属(当時)する栗山貴嗣さんが作ったもので、都内の地下鉄路線をモデルにした立体模型のこと。チューブで再現した地下鉄の各路線内には、シンボルカラーに染めた色水を流している。そこに時折気泡が混じるため、まるで列車のように動く様子を見ることができる。https://youtu.be/sBvHvbDiyeQ空を飛ぶ鳥の視点で描かれた絵図のことを鳥瞰図(ちょうかんず)と言うが、残念ながら地面の中まで見通すことはできない。
モデリングはなぜ失敗するのか―― 悪いモデル、汚いモデル、意味がないモデル:プロジェクトを成功させるモデリングの極意(4)(1/10 ページ) 誰もが失敗したくてモデリングする訳ではないのに、失敗しているモデリングを見る機会は減りません。今回はモデルの失敗例を通じてその原因を探ります。 「モデリングはなぜ失敗するのか」――今回はモデリングが失敗する原因を探っていきましょう。誰しもが失敗したくてモデリングをしているわけではありません。しかしモデリングが失敗している例を多く見かけます。 どこがいけなかったのか、何が悪かったのか、なぜ私たちはモデリングに失敗したのか。今回はモデリングで失敗する原因を見つけていき、これらの失敗から学んでいくようにします。 はじめに 連載の第1回と第2回ではモデリングの目的や手法、ツールを見てきました。前回の第3回ではUMLやSysMLの使いにくいところとその対処法
「わたし」は新米のエンジニアである。最近、先輩からオフィス備品類の在庫管理を手伝うようにいわれた。ペンだとかノートだとかフォルダとかいった文具類が中心である。これまである意味、ルーズな管理だったが、経費節減の折、きちんと在庫数量を管理した方がいい、と部長が方針を出したとのことだ。今まで、各人が勝手にネットからモノを注文して取り寄せ、請求伝票だけが部の庶務係に回される。これをやめて、部で必要数量を考え、集中的に購入し、部のキャビネに保管しておく。そして各人が必要時に庶務係に申請して受け取る、という管理方式にかえることになった。その、キャビネの在庫管理の仕組み作りが、「わたし」の仕事だ。 在庫管理の仕事ははじめてだ。だからいきなり部の仕組みを作り始める前に、たとえば自分の家のモノを在庫管理するとしたらどうするかを考えてみることにした。題材は何でも良いが、出入りの多い食べ物にしてみよう。 在庫管
平鍋 「モデリング」してますか? 今日は「動詞de!! モデリング」の「考え方編」ということで、どうやってこのモデリング手法が機能するのか、という原理について、お話をいただきます。(動詞de!! モデリング – (1)導入編 / (2)実践編 / (3)C言語編) では、萩原さん、お願いします。 誰でもできるように設けた2つの基準 – 妥当性確認と検証 萩原さん 今回のモデリング、特徴的にはですね、「BeforeからAfterへの変換手順に従って進める」という所です。これはいわゆるトップダウン的な方法ですね。モデリングに慣れた人にとっては冗長に感じるかもしれませんが、やはり「誰でもできる」ということを考えた場合ですね、明確な手順と基準があった方がやりやすくなります。 特徴を言いますと、まず「変換手順」があるという事です。正しいものを正しく変換すれば、「最後まで正しい」というトップダウン的な
「ドメイン駆動設計」を読みなおすうちに、ユースケースとは一体何なのか、ユースケースはどこで役立つのか、という疑問が湧いてきた。 以下ラフなメモ書き。 理解できたら後で追記していく。 【0】ユースケースは謎だ。 ユースケース記述の書き方、ユースケース図の良い書き方、などを色々読んできたし、試してみたけれど、何かしっくりこない。 結局、画面設計書やバッチ設計書、システム構成図、DB定義書などのような大量のExcelドキュメントばかり作って、システムの全体概要がすぐには理解できない。 本来、ユースケースは、ユーザ観点でシステムが提供するサービスをまとめたものであり、ユースケースを見れば、システムの機能概要が分かるはずなのに、僕の経験ではユースケースが使われる場面が少ない。 理由を考えてみると、ユースケースの使い道が分かっていない気がした。 以下、疑問をリストアップしてみる。 【1】ユースケースの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く