ITエンジニアの「やってはいけない」---目次：ITpro
設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編
モノ・コト分析の段階的モデリング
コトを関連クラスとして扱った方が自然で分かりやすいと筆者は思いますが、皆さんはいかがでしょうか。関連クラスをもう少し用いた方がモデリングは行いやすいし、人の作成したモデルも理解しやすいと思います。 今回はステレオタイプを用いてモノとコトを識別し、注文から納品・請求の業務フローをサンプルとして注文の状態遷移を考えてみます。 関連クラスの問題 過去2回にわたって関連クラスは使いやすいというお話しをしてきましたが、UMLのルール上の1つの問題点について触れておきたいと思います。 第13回「モノとコトによるモデリング」で注文の例を関連クラスで説明しましたが、実は問題があります。関連クラスの両側のインスタンスを固定したとき、関連クラスのインスタンスは一意に決まるというUMLのルールがあります。関連クラスに多重度の指定はできませんが、暗黙的に1に固定されていると考えることもできます。 この注文の例を関
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://soa.omg.org./SOA-Info-Day_12-06.htm
Input Process Output
矢沢久雄の早わかりGoFデザインパターン 目次：ITpro