すぐに忘れる脳みそのためのメモ

ラベル モデリング の投稿を表示しています。すべての投稿を表示

2008年2月19日火曜日

体調を記録するアプリケーションの作成 - UML で概念モデリング 2

前回、太郎くんの、日々の病気の症状の記録をモデル化することを考えた。ここで再度、太郎くんの記録しておきたい症状の例を挙げておく。

2007.4.1 : 今日も頭痛が朝から続いている。夕方には、腹痛も加わってきた。
2007.4.2 : 朝は昨日よりも頭痛は和らいでいた。昼間、吐き気あり。夕方からは眩暈も加わってきた。

最後には、以下のようなモデルで「症状」の記録を表現した。

特定の身体部位とは結びついてない症状

上記のモデルを作成するとき、「身体部位」と「感覚」の組み合わせによって表現される症状を中心に考えた。では、症状の記録の例にあった、「吐き気」「眩暈」はこのモデルで表現できるだろうか？

まず、「吐き気」について考えてみる。吐き気というのは、人が感じる感覚である。では、どこで吐き気を感じるのだろうか？喉だろうか、胃だろうか、それともその両方だろうか？一般的に吐き気と言った場合、頭痛のように特定の身体部位と結びついていないように感じる。つまり、症状を感じる身体部位がハッキリとしていない。

「眩暈」はどうだろう？眩暈は感覚だ。では、目で感じているのだろうか？それとも、脳だろうか？頭だろうか？やはり、「吐き気」と同じく、ハッキリとどこで感じるか身体部位を特定できないように思える。

こういった症状があった場合、上記のモデルでは対応できない。そこで、以下のように変更した。

080219-002

「吐き気」「眩暈」のように、特定の部位と結びついていない症状を表現するために、「症状の種類」というスーパータイプを想定した。これまで考えてきた、「頭痛」「腹痛」のような、特定の身体部位と感覚によって表現される症状は、そのサブタイプとして「身体の局所的な症状の種類」というクラスを作成した。身体の部位を特定できる症状は、症状の中でも特殊な症状として考える。

定期的に記録したい症状と、突発的な症状

病気において、症状というのは、ある程度中心となるものがある。定期的にある症状と、たまにしかない突発的な症状に分かれる。太郎くんの場合、頭痛は毎日ある。中心となる症状のため、「朝」「昼」「晩」と毎日どのくらい痛みの程度が変化しているか記録している。それに対して、手や足の痛みはめったにない。また、頭痛以外の体の痛みも記録しているが、中心となる症状からは、ややはずれるので、一日トータルで考え、どの程度であったか評価し、記録すれば十分であるように感じている。

そこで、症状の中でも定期的にチェックして記録するものと、そうではないものを分けて考えていくことにした。また、症状をカテゴリに分けて見ることができるように、症状を分類できるようにする。例えば、「眩暈」「吐き気」は「脳神経症状」として分類できるようにしたい。

以下が、上記を踏まえたクラス図になる。

「症状のカテゴリ」は、あるカテゴリーが複数のカテゴリーに所属しないように、ツリー構造となるようにした。

「定期的な症状のチェック」は、特定の期間において、どの症状をどの時間帯で評価するのか定めるためのものである。期間の属性を持ったのは、定期的に評価したい症状が変化する可能性があるためだ。

CCC

<< 体調を記録するアプリケーションの作成 - UML で概念モデリング 1

2008年1月21日月曜日

ブログに見られる人間関係を UML で概念モデリング 1

ブログには、網の目状に広がる人間関係の連鎖が見られる。知合いのブログを見ていると、コメントやトラックバックに、その人を中心とした人のつながりが見えてくる。

Google Reader のような RSS リーダーを使っていると、「自分から見たブログ同士のつながりを記録できたらいいのになぁ」と思うことがある。例えば、ある人のブログの RSS を読んでいて、同じ日付にその人の知合いは何をして何を考えていたのがわかったり。

以下のようなインターフェイスを持ったアプリがあったらおもしろい。各四角はブログを表わしており、同じ日付のブログの内容を眺めることができるとする。

仲のよい友人とだけ、人間関係のネットワーク図を共有し、「これこれこういうつながりのあるあの人が、こんなこと言っているけど、どうなんだろう？」という具合な話ができるかもしれない。それをブログのような形にすれば、特定の人間関係のレイヤーにのみ存在するコミュニケーションが Web 上で可能になる。その他にも、「関心の対象となるブログを書いている人」の「友だちのパートナー」の一覧を取得して、その人たちの物の考え方や感じ方を比較してみたり、いろいろできそう。

結局、おもしろそうな点は何かと言えば、特定の点 (関心対象のブログ) から、ネットワークを辿り、そこにおける集団がどのようなことを考えているか把握できること。特定の点を考えずに抽出すると、その点 (人) というバイアスがかからず、平坦で均一化された情報に目が行ってしまう。特定の点があるからこそ、情報が歪み、その歪みがおもしろさをもたらす。

話が拡散してズレてしまった。 (+_+) モデリングしよう。

例

A くんは、毎日、 B さんのブログを読んでいる。B さんのブログには、たくさんのコメントが寄せられる。コメントをしている人の中には、自分でブログを持っている人もおり、B さんの実生活における知合いも含まれている。

A くんは、B さん経由でいろいろな人のブログを読むようになった。例えば次のような場合がある。

C さんは、B さんの高校時代の友人である。
D さんは、C さんの旦那である。

B, C, D の 3 人のブログを読んでいるときは、その人のハンドルネームを見れば、B さんとどのような関係なのかすぐにわかった。

しばらくして、徐々に興味の対象が広がってきた。

E さんは、C さんの妹で、Bさんにとっては中学時代の友人 (部活の後輩) である。ブログの内容がともておもしろい。
F さんは、B さんのブログによくコメントをしているが、B さんとの関係はわからない。
D さんは、もう一つ別のブログを別のハンドルネームではじめた。

要求

このように、網目のように読む対象が増えてきてしまった。今では、ブログにおけるハンドルネームと、誰がどういう関係なのかわからりにくくなってしまった。今後も増加していくと考えられる。これを把握できるように整理したい。

分析

人とブログ

最初は、「人」と「ブログ」との関係。

「D さんは、もう一つ別のブログを別のハンドルネームではじめた。」

「E さんは、C さんの妹で、中学時代の友人であり、いつも記事がおもしろい。」

上記の例より、「人」は複数の「ブログ」を持つことができる。

また、ブログに対して「おもしろさ」という観点から評価していることより、ブログに対する評価項目が必要となる。右の図は、それを表現したクラス図。

抽象的な「関係」

人と人との関係には、「友人」「夫婦」「姉妹」などのように種類がある。これを示したのが下図の左側。

関係の種類として「不明」があるが、これは「F さんは、B さんのブログによくコメントをしているが、B さんとの関係はわからない。」という場合があるためだ。

人と人との関係は、「高校時代の友人」や「中学時代の親友」と言うように、ある一定の時期 (期間) 形成さされる。人の一生において、特定の時期には「幼児期」や「思春期」のように呼び名がある。時期という視点で種類に分け、これを表わしたのが上図の右側。

具体的な「関係」

上記の関係が「抽象的な関係」だとすると、個別の人と人の間で成立する「具体的な関係」というものを考えることができる。例で述べた

「C さんは、B さんの高校時代の友人である。」

という文をオブジェクト図で表現したのが左図である。

ここでは、「関係」というオブジェクトが中心となって B さんと C さんをつなげている。この「関係」は、B さん・ C さんの間においてのみ成立している特定の「関係」を表わしている。「友人」などの「関係の種類」という抽象レベルから見ると、一段階、具体的なものと言える。

具体例でチェック

例で挙げれられていた関係を、全て表現できるか確かめてみた。

C さんは、B さんの高校時代の友人である。
D さんは、C さんの旦那である。
E さんは、C さんの妹で、Bさんにとっては中学時代の友人 (部活の後輩) である。ブログの内容がともておもしろい。
F さんは、B さんのブログによくコメントをしているが、B さんとの関係はわからない。
D さんは、もう一つ別のブログを別のハンドルネームではじめた。

ここで表現されていないのは次の点である。

D さんは、C さんの「旦那」であるか判別できない
- → 「人」の属性に「性別」の項目を加える。
E さんは、C さんの姉か妹かわからない
- → 「人」の属性に「年齢」の属性を加える。または、姉妹の分類を分け、「関係」に方向性を持ったサブクラスを作る。( ← 今、思いついたので、あまり検討してない ^^; )

とりあえず、要求に対して必要性の低いものは、置いておくことにする。

クラス図

ここまでをクラス図にしたのが以下のもの。

「関係」の「時期の種類」に対する多重度が「多」なのは、ある関係が複数の時期に渡って継続することがあるためである。

続く... CCC

2008年1月4日金曜日

体調を記録するアプリケーションの作成 - UML で概念モデリング 1

使用するツール

JUDE/Community

現状

「太郎」さんは、病気になってから、いろいろな症状が毎日続いている。日記のように毎日記録をつけているが、単にテキストとして保存しているだけ。同じような症状が繰り返すこともあり、毎日記録をつけるのが面倒だ。

例えば、次のように記録している。

2007.4.1 : 今日も頭痛が朝から続いている。夕方には、腹痛も加わってきた。

2007.4.2 : 朝は昨日よりも頭痛は和らいでいた。昼間、吐き気あり。夕方からは眩暈も加わってきた。

要求

毎日記録をつけて、症状がどのように変化しているか把握したい。現状では、日記を読み返して、過去にあったことを定期的に把握している。漠然とした傾向をイメージするだけである。

分析

最初に、関心の中心である「体調」という言葉について考えた。この言葉の日常的な用法は二つある。

(A) 「今、ちょっと体調が悪い」
(B) 「昨日から体調を崩している」

(A) は、ある時点における「具合」を表わしている。それに対して、 (B) は、特定の時点から現時点まで、一定の期間の状態を表わす。

日常的に使われる言葉は、コミュニケーションが成立すればよいので、曖昧さを含んでいても問題はない。しかし、状態をデータとして管理する際には、それではちょっと具合が悪い。

太郎さんは、日記のように、毎日体調を記録する目的で「体調」という言葉を使っている。そこで、ここでは「体調」という言葉を、次にようにとらえることにする。

「一日を単位とした体の状態」

体調を、一日に生じる様々な「症状」によって把握する、トータルな状態を表わす概念として見なして考えた。

これをクラス図にしてみた。

上記の例として挙げた記録のオブジェクト図を描いてみた。

このモデルでは、テキストとして記録しているものと比べると、それほど変わらない。違うのは、各症状を特定の基準で個別に表現しているところ。

「症状」について

症状には「頭痛」「腹痛」「吐き気」などのように種類がある。また、「朝から頭痛がした。」のように、「朝」「昼」「夕」のような時間帯と関係している。これを表現したのが下図。

記録内容における「症状の種類」「時間帯」以外の要素については、とりあえず症状の「備考」属性に記録することによって対応することにした。

例では書かれていないが、例えば、頭痛の痛さの程度を 5 段階で自己評価して記録することより、症状を比較することができるようになる。そこで、症状に「程度」という属性を加えた。また、「頭痛が朝から晩まで続いていた。」のように、症状の種類は複数の時間帯と関係するので、一つの症状に対して複数の時間帯を設定できるようにした。

上記をオブジェクト図で表現してみた。

これを見ると「程度」という属性を入れた意義がわかる。例えば、上図における 2007.4.2 における「頭痛」の「備考」属性の値「昨日よりも和らいだ」は、「程度」属性で表現できる。つまり、2007.4.2 における「頭痛」の値を、2007.4.1 の頭痛の程度よりも、大きい値が設定することだ。

「症状」の表現

症状という言葉は、思ったよりも複雑。 (+_+) 例えば、「頭痛」について考えてみよう。頭痛とは、「頭」が「痛い」ことである。「腹痛」ならば、「腹」が「痛い」ことだ。同様に、腰痛ならば、「腰」が「痛い」ことである。「頭が痛い」と一口に言っても、例えば、頭が「しびれる」ような感じがしたり、頭が「締め付けられる」ような感じがすることがある。つまり、症状というのは、「頭」や「腹」のように、「身体部位」と、「痛い」や「しびれる」のように、「感覚」の組み合わせによって表現できる。

おもしろいことに、日常に使っている言葉には、「頭」が「痛い」ことを「頭痛」と一単語で呼ぶことができるが、日本語では「頭」が「しびれる」ことを「頭しびれ」というようには言わない。これは、「頭が痛い」という症状が圧倒的に多く、「頭がしびれる」ということが少ないため、そのような言葉をわざわざ一単語で表現する必要性がなかったためだろう。オブジェクト図で表わすと、次のようになる。

では、ここで症状の種類を変え、「背部痛」について考えてみることにする。背部痛の症状として、「肩甲骨の内側が痛む」や、「胸椎の辺りが痛い」という場合がある。これは「背部痛」が、背部という範囲よりも細かな部位に生じるということだ。先ほどのモデルに即して言えば、「背部」と呼ばれる身体部位に、「肩甲骨の内側」と「胸椎の辺り」という部分があるということ。そして、それぞれの痛みは伴に背部痛に分類される。これは、症状の範囲に全体と部分の関係があり、部位の分類が階層化されていることを示す。これをクラス図にして表現すると、次のようになる。