データモデルとUIの整合性をとる

ソフトウェア開発で要件を詰める際に、データモデルとUIの整合性に気をつけている。 特にどういった点に気をつけて整合性を確認しているか書く。

データモデルとは

一言で言うとデータをモデリングしたもの、つまりソフトウェアが扱うデータを整理して構造化したものこと。 ここでは、どのようなデータがあってそれらがどんな関係性か表した図のことをざっくり言っていて、特定の技術(例えばRDBMS)に特化した図までは想定してない。

なぜ整合性をとりたいか

整合性が取れてないと、あるユースケースでUIを通してデータを表示したり操作することが困難だったり、可能であってもシステムの複雑度を無駄にあげてしまうことがあるため。

整合性をとる際の観点

1. nullが入るかどうか

nullは演算が定義されてないため、演算を独自で定義する必要がある。*1 なので演算の対象となるデータの場合にnullが入る場合、システムが複雑化するリスクがある。

ここでいう演算とは、以下のようなものを指す。

• 四則演算
• 集計
• 比較
• 条件式の真偽値

nullが入る場合のシステムの複雑化とそれがユーザーにもたらす価値を比較して、仕様の決定をするのが良いと思う。

例えば

食事の栄養素を保存、表示するとして 栄養素が測定できない場合にnullを保存する場合。

栄養素に関する演算が入りそうであれば、仕様やシステムの複雑さが上がる 例えば１日あたりに摂取した栄養素を集計する場合にnullな栄養素が入っていた場合、 集計結果をnullとして扱うかもしれないし、nullな栄養素は０として集計するかもしれない。 そこらの仕様を議論して、栄養素を集計する場合の演算を実装する必要がある。

2. 多重度の整合性が取れているか

多重度とは、あるデータともう一方のデータの数の関係性のこと。1:1、1:n、n:n といったものを指す。

提案されたUIの背後にあるデータモデルと、実際あるべきデータモデルの多重度と違う場合がある。その場合は何故違うのか掘り下げてみる。

例えば

スマートロックのアプリケーションで、データモデル的には錠前: 鍵 = 1: n だった。つまりある錠前に対していろんな鍵を持てた。これは他の要求によってそうする必要があった。 なのに、提案された解施錠を行うUIは 錠前: 鍵 = 1: 1 になっていた。 この場合、なぜそうなっているのか確認するのが良いと思う。 例えば特定の鍵を選択していることが前提で、選択する画面が考慮から漏れていたのかもしれない。 ここらを掘り下げることで良い議論ができるんじゃないかと思う。

*1:以下の記事がNULLについて参考になった。よりデータベース寄りの話をしている。 https://speakerdeck.com/sinsoku/db-design-without-updating?slide=5