モデリングカフェ 第2回：社員と辞令をモデリングする（読者解答モデル）

読者の皆様から、たくさんの解答モデルを頂きました。ありがとうございました。こちらのページでは、残念ながら本文で紹介することができなかった解答モデルを記載します。オブジェクトの広場 メーリングリスト等で意見交換していただければ幸いです。

• 岩沢正樹 様の解答モデル
• さいごさわ 様の解答モデル
• たつ 様の解答モデル
• YY 様の解答モデル
• holic 様の解答モデル

読者解答1：岩沢正樹 様

• コンセプト

  辞令を、社員と組織要素（部署、職級）との関連するクラスと捉えました。
  イメージとしては、部署と階級による行列のマスに、社員を配置するイメージです。
  

  また、命令については、

  • 各組織要素に対応する命令を汎化・特化で捉える。
  • 命令が生成されるときは、必ず対象（主語、目的語に相当）が存在する。
  • 辞令は、必ず命令を含む。
  • 一人の社員に有効な命令は、入社時に少なくとも１つは発効される。
  • 命令の種類を汎化・特化で捉えたので、同時に有効な命令は複数。

  というような定義としました。

• モデル
  
  図 1 岩沢正樹 様の解答モデル
• 感想
  • 難しかったところ
    • 最初の第１歩としての、「辞令とは？」を掴むのに苦心をしました。 最初、１枚の紙をイメージしてしまい、実体のあるクラスと捉えて モデリングを始めました。しかし、どうしても無理があり、今一度 捉えなおしました。
    • 「辞令」を「関連クラス」とするか「関連するクラス」とするか は、定義により揺れ動きました。今回は、上記コンセプトに 基づいて「関連するクラス」としました。
    • 幾つかの種類の命令を如何にして、まとめるか、また、汎用性を 上げるかに苦心しました。（例：給与表に関する命令の拡張） 命令種別は、それぞれの対象により変更の可能性もありますが、 とりあえず汎化により抽出しました。
  • 自己評価

    今回は、第１回ほど自身がありません。もう少し、良いモデルが あるのではないかという感じを持っています。そのため、１０点 満点で言うと５～６点程度を付けたいと思います。

読者解答2：さいごさわ 様

• コンセプト
  • 辞令は、所属と肩書を任命する際に用いる書類である。
  • 辞令の発令は人事権が利用される。
  • 人事権は職権の一種であり社員により保持される。
  • １辞令で１社員が任命される。辞令が発令されない社員もいる。
• モデル
  
  図 2 さいごさわ 様の解答モデル
• 感想
  • 難しかったところ
    • コンセプトを決めること。
  • 自己評価
    • 社員と辞令の関係について、本質を掴めなかったので、モデルの納まりが悪い気がします。

読者解答3：たつ 様

• コンセプト
  • 一般の人(社員と同じ視点の人)が辞令を理解するためのモデル
  • ある時点における辞令のモデルとする(今までに受けた辞令の履歴は考慮しない)
  • 配属前の状態 及び 解雇/退職後の状態 は(会社における)地位が無い状態である。
  • 複数の役職を兼務可
  • 複数の地位に付く場合も辞令としては1つ
  • 辞令を受ける社員は一意に特定される必要があるので従業員番号を属性として追加
  • 社員ー地位間の関連は現在の地位を\表すが、辞令後の地位と対比させる 意味で辞令前というロール名を使用
• モデル
  
  図 3 たつ 様の解答モデル - クラス図
• 感想
  • 難しかったところ
    • 最初は辞令クラスを設けずに、役職クラスを用いて辞令のモデリングを試 みましたが、地位が変わることを表現できないと思い断念しました。
    • "発令する"クラス(人事クラス)を作成することも検討しましたが、入れる と"社員と辞令の関係"というより"辞令のシステム"に視点がシフトしそう だったのでやめました。
  • 自己評価

    地位が変わることは表現できていると思うので及第点。

読者解答4：YY 様

• コンセプト
  • 辞令とは
    • 会社が
    • ある問題を解決するために
    • 社員に対し、
    • ある日付に行う
    • (社員を活用した)解決策の一つ
• モデル
  
  図 4 YY 様の解答モデル
• 感想
  • 難しかったところ

    「辞令」というモノが何故あるのかを見いだすのが、難しかったです。

  • 自己評価

    属性が洗い出せなかったのと、 コンセプトと図が合っているのかあまり自信が無いので、 50%ぐらいかと思います。

読者解答5：holic 様

• 解答モデルについて
  • 人事部が使う前提なので、過去の辞令の履歴による従業員の状態変化が追えること。
  • やっぱり、視点と視座がお題に命じされていないところ。
    べつに、部署の歓迎会、昇進祝いパーティを企画するシステムの概念モデルを書いても 面白かったかなと。
  • ひねりがなくて、面白くないモデルになってしまいました。
• 検討

  とりあえず、視点も目的も提示されていないので、ここは素直に、

  • 視点: 会社の人事部
  • 目的: 人事システムの概念モデルの決定

  としておこう。
  

  オブジェクト（もの）の候補を抽出する。

  • 山田さん、田中さん、花山さん
  • ジュニアSE、ミドルSE
  • 技術２部

  それぞれ

  • 従業員(社員って混乱を招くことがあるので、ここでは従業員とする)
  • 職級
  • 配属先(組織)

  というクラスとなるだろうか？

  「もの」をつなぐ「こと」にあたるのが、題材の辞令になるだろうか？
  ここまでで、初期クラス図を描いてみる。

• 初期モデル
  
  図 5.1 holic 様の解答モデル(初期モデル)

  ここで、多重度などを考えていこう。

  • 辞令には、職級を決める辞令と、配属先を決める辞令があるらしい。
  • 職級と配属先を同時に、単一の辞令で変えるはあるのだろうか？
  • 辞令が出たところで、いつから有効かを決めなければいけないので、 発行日だけでは情報が足りない気がする。
  • 配属先は、複数になることが可能だ。「技術２部」兼「人事部教育課」とかね。
  • 職級は、同時に複数になることはない。
  • 職級には、上下関係があるらしい。「昇格しました」になっているからね。 当然「降格しました」もあるに違いない。
  
  

  情報は、問題に含まれていないので、勝手に決めることにする。

  • 辞令は、職級辞令と配属辞令の２種類があって、 それぞれ職級と配属のみを変更する。単一の辞令で、職級と配属を決めることはない。
  • 辞令は、発行された日とは違う、その辞令が有効となる発効日付を持つ。
  • 配属辞令は、同時に複数の配属がありえるので、 以前の辞令を有効にするか無効にするかを選べる。 技術１部と技術２部への配属辞令が、田中さんに連続して出た場合、 後の辞令が前を取り消すという指定がなければ、田中さんは、 技術１部と技術２部に２重所属することになる。
  • 職級辞令のほうは、複数あった場合、現在日より前で、 一番近い発効日をもつもので、現時点での職級が定まる。
• モデリングの方針

  以上をふまえて、モデリングの方針を考える。

  • 職級辞令と配属辞令は、それぞれ辞令のサブクラスにする。
  • 辞令は、以前の辞令の効力を無効にするリンクがあるとしよう。

  ここまでを、クラス図にすると、こうなる。

• モデル
  
  図 5.2 holic 様の解答モデル

  辞令クラスの自己参照は、以前発行された辞令の効力を上書きするというリンク。 職級クラスの自己参照は、職級間の上下関係をあらわす。

  あとは、辞令を撤回した場合の処理をどうしようかとか、配属先の組織構造を考慮すべきかとか、 入社と出社をどう扱っておこうかとか、いろいろ考えないといけないところはあるが、 今回の宿題の趣旨から外れると思うので、今回のモデリングは、ここまででおしまい。

  ほんとうは、ちゃんとオブジェクト図を描いて確かめるべきであるが、そっちもさぼり。 ごめんなさい。