Designing Classes from Use Case with Actor Inheritance

[TheInsider]

Hi,

I posted this in the UML forum but then found this forum, which is probably a better place to ask this. I'm new to good class design . Anyway, I'm working on a Class diagram that has me puzzled. To make this easy, I'll use an analogy rather than describe my project in great detail. Let's say I have a Use Case diagram, and on it, I have two actors:

Tenant
 /\
 |
<<inherits>>
 |
Landlord

So, essentially a tenant lives in a building and so does a landlord.

Now, let's say that Tenant can "Do X to Building" and "Do Y to Building", and Landlord can "Do Z to Building" because Landlord has extra special privileges.

Here's where I'm having a problem. Assuming that I have a Tenant class and a Building class as follows:

================
 Tenant
================
 -phoneNumber
================
 +getPhoneNumber()
 +setPhoneNumber()
================
| 0..*
|
| /\
|has
|
| 1
================
 Building
================
 -address
 -landLordPhoneNumber
================
 +doXtoBulding()
 +doYtoBulding()
 +doZtoBulding()
================

Is there really a need for a Landlord class? Assume for a moment that Tenant.phoneNumber is a unique key. Wouldn't it make sense to simply check who is calling Building.doZtoBuilding() within the method doZtoBuilding() and if that Tenant object doesn't have the same phoneNumber as is stored in Building.landLordPhoneNumber then don't allow the method to execute any further?

Since the "do..." methods are acting upon building, it doesn't make sense to make them methods of Tenant or Landlord classes. And, if the "do..." methods aren't methods of the Tenant or Landlord classes, then the Tenant and Landlord classes would essentially have the same properties and methods. And, since a Landlord is also a Tenant, having a Landlord class would be redundant using the above design.

I hope that made some sense. I'm trying to figure out if this is a bad design, and if there is a need for a Landlord class.

Thanks

 

[Prattaratt]

I think I would try and do a "person" object as an ancestor object to both tenant and Landlord; both have commonality such as a phone number, address, name, etc... but for instance a "tenant" pays rent, while a "landlord" does not, and a "landlord" would be able to modify the building, where the "tenant" would not.. I see the "tenant" and "landlord" as being distinct classes with a common ancestor



90% of all questions can be answer by the Help file! Try it and be amazed.

 

[TheInsider]

Thanks Prattaratt, my guess is that you're correct in your recommendation for the above example. The problem is that my analogy (example) wasn't very good because a tenant and landlord would serve different functions, as you pointed out. My actual design scenario has nothing to do with tenants and landlords but would have taken too much time to describe. In it, the classes representing Tentant and Landlord are actually the same class, only one has the ability to perform a handful of operations that the other can't (like User and SuperUser). The more I read about UML class diagrams, the more I get the feeling that I shouldn't try to design/model User and SuperUser as two separate classes but rather as a single class and use a key or attribute in, say, the System object, to see if the User owns the System (i.e. they created the persistent object and thus have SuperUser privileges like in a file system) or they didn't create the System and thus aren't the owner of the System and only have User privileges. In that scenario, my thinking would be that I model User and SuperUser as inherited logically on the Use Case (assuming that they are considered different business actors performing different roles) but create the class diagram using just a User class with privileges taken care of in the code?

 

[TheInsider]

Sorry, my choice to use the word "system" above was confusing. I should have said:

... the more I get the feeling that I shouldn't try to design/model "User" and "SuperUser" as two separate classes but rather as a single class and use a key or attribute in, say, a "File" object, to see if the User owns the "File" (i.e. they created the persisted object and thus have "SuperUser" privileges [read/write/delete]... just like in a file system) or they didn't create the "File" and thus aren't the owner of the "File" and only have "User" privileges [read/write]. In that scenario, my thinking would be that I show "User" and "SuperUser" as inherited logically on the Use Case (assuming that they are considered different business actors performing different roles in the work place) but create the class diagram using just a single "User" class with all the different privileges handled in the actual code/methods?

 

[BobRodes]

I believe this is one that I answered on the thread741-1410126 in the UML forum. If I might suggest it, if you move a post to another forum, cross-reference the threads by copying and pasting the numbers. That makes it easier for everyone to avoid double posting answers.

But just to be sure:

<create the class diagram using just a single "User" class with all the different privileges handled in the actual code/methods?

No, that would be pretty tough to maintain. Now, a superuser "is a" user. Superuser's functionality is a superset of user's, and therefore represents a specialization of user. So, create user with all of user's capabilities, and then let superuser inherit them and also add its own.

Bob

 

[TheInsider]

Yes, you answered this question in thread741-1410126. Thanks. I should have updated this thread to indicate that.

I'm actually just finishing the first iteration of my sequence diagrams right now. I implemented your design recommendations, and everything seems to be flowing nicely.

 

[BobRodes]

Very pleased to hear it.