I would like to create a registry of the times a user has viewed audio visual content. I created the following diagram and was wondering if it would be a good way to achieve it.
Note: The AudiovisualContent is connected to DateTimeStamp just as a way to record when it was added to the platform.
The diagram seems formally correct and has the advantage of being very clear on multiplicity and role names for the DateTimeStamp
.
It is diffucult to say if this approach is correct for a "registry". But it makes sense at first sight; I understand from the diagram that:
Profile
(user?) can do several Viewing
and each Viewing
is about one Audiovisual Content
. Conversely, an Audiovisual Content
can be the subject of several Viewing
, and each Viewing
is performed by a Profile
Viewing
(of a given content by a given user) has a DateTimeStamp
Audiovisual Content
has a DateTimeStamp
corresponding to the moment the content was added.What I can further infer from the multiplicities, is that the timestamp corresponds to the beginning of the viewing act (because if it would be the end of the viewing, there wouldn't be timestamp when the viewing starts, so the multiplicity would have been 0..1).
The DateTimeStamp
is a class according to your diagram. The fact that you have a 1
multiplicity on the side of the Viewing
and on the side of Audiovisual Content
means that every single timestamp must be associated with BOTH. I doubt that this is correct.
You could consider using 0..1
instead, which would leave the possibility of having a time stamp associated with only one of the two or none at all. But still the timestamp could possibly have both, with the risk of inconsistency between them.
Personanlly, I'd go for *
to clarify that many viewing and uploading could happen at the same time. I'd probably show it as a property -addedOn: DateTimeStamp
and -viewedOn:DateTimeStamp
.
In reality, the time stamp is very probably a value object. You could then consider making it a «dataType»
; showing it as a property may then seem even more intuitive.
Unrelated: while your current way of modeling Viewing
as a class is perfectly fine, you may be interested to show is as an association class between many Profile
and many Audiovisual Content