OK I like the way this class diagram is
coming along. So at this point I think we
have all the classes that we need. For each
class we specified the attributes or the characteristics of the
class. And we also specified the operations so we
know what the class can do And, I like to
kind of move forward on this, but I first
want to see that you're fine with the class structure.
So that's the way the class structure is going
to be in terms of attributes and operations. So anything
that bothers you? Well, one thing I didn't understand
is how come you put check out over where
the patron when it's really the item being checked
out? Right. Okay. So that actually is you know, is a perfect
segway for the next thing that really wanted
to model. Because what you're talking about is basically a
relationship between two classes which is something we haven't touched on
yet. So we haven't, haven't looked at individual classes. But now, it
is typical, now we are looking more at requirements, we're starting to
find more things about our system, and what you're pointed out right
now is the fact that patron and item are somehow related. So
this checkout operation is not really something that belongs only on in
the patron, because it needs to know about the item. And it
doesn't belong only on the item because it needs to know about
the patron. So, it's something that associates the patron and
the item. Okay. And that's exactly the way we call
in the UML which is the notation that we're using
here this kind of relationship. So, we're going to represent that
by drawing a line between these two classes that tells
us there is an association. And we're also going to
give a name to this. Since this refers to the
fact of checking out items. We're just going to call
it, checkout. Gotcha. And notice that this basically you
know,eventually will end up kind of replacing this attribute. Because
the existence of this association will tell us that
this is checked out. We're, we're not going to, you know,
do it right now, but in the final cleanup
or the diagram, this name will disappear. Okay. Okay.
And so since we started talking about relationships and
associations, is there any other kind of relationship that you
see here? Well, what you just did with checked
out is, it seems similar to the whole issue
of requests. It is, it is. So a request
is something else that happens in both, you know, in
the patron and in the item, it involves both.
And in fact in a request, I would definitely
represent this as an additional association. So I will
just draw an another line between these two that represent
that specific kind of relationship and I will call it
request. So that indicates that this association refers to a
request that also connects the patron with an item. Okay.
And, let's see. Any, anything else that jumps at you?
Yeah, well, how about all these ones down at the
bottom? I mean book and item's got to be
related, right? A book is a kind of item, And
audiovisual... are there associations between them? Can you repeat
that, you said that the book, yeah? Is
a kind of item. Perfect, that's exactly what we're
modeling next, which is, this, what we call the
is-a relationship. So you said, a book is an item?
A book is an item. And, we can model that in the diagram. So, we do that
using another kind of relationship between the classes. So
we're going to represent that as a specialization we call it.
And, a specialization is indicated in this way. Okay?
With this arrow at the end, so a solid
with this kind of arrow at the end. And
we can do the same for book, magazine, reference book
and audiovisual material. So we're all going to connect,
we're going to connect all of them, to the
item, using the same kind of connection. And now
that we have connected all these four, with item
and indicated them in subclasses. That's something else that we can
do. So we can make this kind of cleaner. And I'll
tell you what I mean by that. So now we have
this loanable attribute that refers to item, but it seems to
me from what you were saying before, that loanable is not
really an attribute of an item. Right? It's more of a
characteristic of the type of item. Right. Is that right? Right.
Books, and audio/visual are loanable but the others aren't.
Okay, and so representing it here, it's okay to,
it will work. But it's not really right so from
the style standpoint it doesn't really you know,
it's not the best way of modeling this. What we're going to
do instead, we're going to use this specialization relationship to make
that more explicit. To make it cleaner. Okay, so what
I'm doing here is I'm going to take this hierarchy
of classes, this is just on two levels now, and I'm
going to kind of make it a little richer.
So I'm going to add an intermediate set of
classes. And in particular I'm going to have these two
classes that I'm going to call non loanable item and loanable
item. So, they're both items but they tell me
clearly that some items are loanable and some items
are not. Okay. Okay. And then I'm simply going to
put book and audio video material as subclasses of loanable
item and reference book and magazine as subclasses of non-loanable
item. So, if we look at this diagram now it's
pretty clear what is loanable and what is not. And
it's actually is a very clean, much cleaner
design. And, and I see you've, gotten rid of
the loanable attribute, too. I did. Because at
this point this is already represented by the fact of
having these two classes. And actually, something else that I did
is that I moved all these attributes, value,
due date, renewed and checked out, that makes
sense only for loanable item. From item to
loanable item. So at this point, this really
is telling me that, you know, these
characteristics are just meaningful for the loanable item,
and not for the other ones. Well, speaking of that, the way that you got the
lines going in the diagram here is you still have
request and checked out going to item, even though you
can't request non loanable Items. You can't check out non
loanable Items. Oh, you were right actually. You got me on
that one. You're exactly right. So this associations are between
the two wrong classes. So, I guess, at this point,
you can probably go and fix the diagram yourself. Well,
can we just make the lines go from patron to loanable
item instead of to item? That's exactly the way in which we
are going to fix it. So, we're going to move these two associations down
here. And at this point, this will represent the right relationships in
the, in the diagram, and in the system. Makes sense to me.