危ういデータモデルを見破るコツ - 設計者の発言
ひところよりもデータモデル（ＥＲ図）を作成することの重要性が理解されるようになったが、それでも形だけ整えられて納品されてしまうことがある。「納品しろと言われたからしかたなく作った」ようなモデルはヤバい。素人のイラストにもとづいて高層ビルを建てるような無茶を避けるために、危ういモデルを事前に見破るコツを知っておこう。 ただし、データモデルの「意味的な正しさ」は個別の問題なので立ち入らない。ここではその「見かけ」から危ういモデルを見破るための３つのポイントを紹介しよう。「キー設計が甘い」、「多対多を含んでいる」、「他の設計要素を支えない」といった兆候があれば注意したほうがいい。それぞれを説明しよう。 １．キー設計が甘い データモデルはデータ項目間の「関数従属性」と「ドメイン制約」を示すための図面である。それゆえに、キー属性がいい加減に設計されたモデルは役にたたない。キーはテーブルの存在証明のよ
第11回 プログラマが知らない，デザイナーの苦労
今回は，デザイナーとして，世間やプログラマに対して言いたい放題書かせてもらう。どうか怒らずに最後まで読んでもらいたい。デザイナーの皆さんには，大いに賛同していただける内容になっているはずだ。 デザイナーだって，タイヘンなんだ！ まず，デザイナーという仕事は，非常に誤解されやすい。例えば次のような誤解をうけて，暗い気持ちで日々の作業をこなしているデザイナーも少なからずいるはずだ。 1) デザイナーという職種に対する，先入観がある 世間（顧客やエンドユーザー）には，「すべてのデザイナー」＝「技術に無知」だという先入観がある。「デザイナー」とは「Webページの配色とレイアウトをする人」だから技術を知らなくて当然，むしろ知らなくてよいとする傾向すらある。開発ツールが完全分業に向けて進化しているのだから，デザイナーはビジュアル・デザインのことだけ考えていればいいという意見を持っている人もいるだろう。
オブジェクト指向で実現できる保守性・拡張性
オブジェクト指向開発を行えば、保守性・拡張性が良くなるといわれますが、本当にそうなのでしょうか？ 第1回「保守性と拡張性の定義」では、現状のシステム開発の問題点を指摘し、そのうえで、そもそも保守性・拡張性とはどのようなものなのかを説明しました。今回は、拡張性・保守性を高めるための重要な考え方について解説をしていきます。 オブジェクト指向による問題の解決 前回「ソフトウェアにおける保守性と拡張性の定義」は「機能分割」のような従来型の開発手法における問題点を指摘しました。今回はこれらの問題をオブジェクト指向ではどのように考えるのか、また、どうすればこのような問題を解決できるのかについてお話ししたいと思います。 ［1］ 下流工程における複雑さの解決についての考え方 （1）クラスって何だろう 最初にクラスとはどのようなものか考えてみましょう。オブジェクト指向では、必ず出てくるクラスとはどのようなも
保守性・拡張性に優れたシステムを作る（1） ― ＠IT
本連載は、オブジェクト指向言語（Java言語など）の経験がある方に、オブジェクト指向における分析設計の流れ・考え方を理解していただくことにより、少しでも現状の改善に役立てられることを目標としています。 一般的に、オブジェクト指向を使うと、保守性・拡張性に優れたシステムが作れるといわれています。しかし、実際には、「オブジェクト指向を使った開発手法のどの部分が保守性・拡張性に貢献するのか分かりにくい」というのが実情ではないでしょうか。この連載では、システム開発における分析から実装の中でも、特に保守性・拡張性の視点から重要なポイントをピックアップして、説明していきたいと思います。 連載第1回は、まず、現状のシステム開発（ビジネス・アプリケーション）における分析設計手法の問題点を整理し、変更性・拡張性の重要性と定義を説明したいと思います。 現状のシステム開発における問題点 ビジネスアプリケーション
ITアーキテクトってなんだ？ (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 某所でIT関連書籍の編集者に「あなたはITアーキテクトを名乗っておられるが、あなたはITアーキテクトをなんだとお考えですか？」と聞かれました。 そのときの僕の答えは「アプリケーションの"クライアントにとっての価値"を説明できる人」というものです。そのアプリが、どんなに技術的にださかろうとクライアントに、その価値を説明できればいいわけです。そういう説明責任がアーキテクトの任務だと思っています。アーキテクトがアーキテクチャーの勉強をするとか、そういうレベルは当たり前です。その上で何が必要かと聞かれれば、言葉にする力というわけです。 で、素材の美学―表面が動き始めるとき…という建築系の本を読んでいていい言葉を見つけました。第1章ではスピロ・コストフの「建築家」という本からの
ITが建築から学べるものは多い - モジログ
arclamp.jp アークランプ: ITアーキテクトってなんだ？ http://www.arclamp.jp/blog/archives/000765.html ＜僕が考えたアーキテクトの仕事とは「提案したシステムがいかなるもので、どのような形であるべきかをクライアントとプログラマに示す」ことであり、それに必要な言葉を定義することが最初の作業となるわけです。 特にコールハースの「定義された言葉こそがデザインを可能にしている」という言葉は深いです。 結局、クライアントにしてみれば「なにができる」「どんな感じ」といったイメージでしか語ることができません。そうしたものを＜言葉＞として定義していくことがアーキテクトの役割なのかもしれません＞。 これはすばらしい一節。 「定義された言葉こそがデザインを可能にしている」って、いいフレーズだなあ。 最近のyusukeさんは建築を引き合いに出してITを語
システムの論理設計を構造化するための視点 - 設計者の発言
業務システムの論理設計を構造化するためのさまざまな視点がある。それらの意味合いを区別しないままに設計情報を漫然と眺めるだけでは、読み手として重要な項目を読み落とすし、設計者として複雑膨大な設計情報を「分割して統治」することにも失敗する。 「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」をとりあげて、システムのあり方を眺めるためのいろいろな視点を見てみよう。 ◆業務フローの視点で眺める ＸＥＡＤにおいてシステム定義は、ツリービュー上の「業務フロー」、「職種別担当業務」、「サーバーモジュール」の３つのまとまりとして示される。ひとつめのまとまりの「業務フロー」の下位には、「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」では「現預金口座管理の流れ」、「手形管理の流れ」、「売上収益回収の流れ」といった１６個の要素（ノード）が並んでいる。それぞれのノードを選択すると、データフローダイアグラム（ＤＦＤ）でまとめられた「業務（後
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
