CODEWITHSUNDEEP
umlabstract-class
amadzebra
amadzebra

Reputation: 185

UML abstract classes?

So I'm currently self-teaching myself UML and I took an online quiz to help strengthen my understanding of it.

One of the questions asked:

How do you model the following situation with a UML2 class diagram:

"There are multiple different bird species, e.g. blackbird, thrush, and starling."

And two available options were:

available options

The diagram on the top is correct (and I understand why), however, the diagram on the bottom is incorrect. Why is this? Since the three birds inherit from the abstract class bird and conform to any abstract methods, aren't they all birds?

Upvotes: 1

Views: 5964

Answers (3)

Wolfgang Fahl
Wolfgang Fahl

Reputation: 15769

The requirement in the quiz says: There are multiple different bird species, e.g. blackbird, thrush, and starling

But it does not says anything about what information you should hold about the bird species. So my first assumption is that the user would only be interested in the type.

The UML diagram:

Bird Class

is a valid solution for this requirement. The two options in your quiz are also both valid solutions depending on how you look at the requirement. The requirement gave three examples which are all modelled explicitly in both solutions. "e.g." means there could be other birds and this fact is better described with the first solution. In the second solution you can have no instances of "Bird" that are not in the list of examples.

But this solution would only make sense if you could have some attributes and operations which are not shown - IMHO the minimum would be to keep track of the bird type - it is very awkward to retrieve this from the class name in most implementation environments.

Personally I do not think it is a good way to explain inheritance with such examples as in your quiz. Inheritance is costly in implementation (e.g. in most programming languages you end up with separate source code files per inherited class) and this cost should give you a certain benefit. This is mostly the case when the things to be depicted differ in theie attributes and behavior and you need different implementations. "Blackbird" and "Bluebird" might differ only in color (the color attribute is the discriminator). IMHO in this case it is better to have: Bird with color than Blackbird and Bluebird

Upvotes: 1

muszeo
muszeo

Reputation: 2352

There's two possible answers to this I think:

  1. The top is incorrect logically since you can't create an instance of a Bird on its own. Bird is an abstract classification of all bird species. You can only create Thrushes, Starlings and Blackbirds. I'm not sure what a Bird instance would look like, but it would be supernatural.

  2. The bottom is incorrect syntactically because the abstract constraint should be applied after the class's name and type.

Personally I think I'd let the #2 one go (it's a mistake, who cares?) and focus on #1 which is, if I was in the business of birds, more important.

Upvotes: 2

qwerty_so
qwerty_so

Reputation: 36295

The UML 2.5 spec says on p. 98

The isAbstract property of Classifier, when true, specifies that the Classifier is abstract, i.e., has no direct instances: every instance of the abstract Classifier shall be an instance of one of its specializations.

So whether or not Bird is adorned with the keyword abstract results in the restriction of being able to not/instantiate it. If you need a Bird instance you leave it away. If you want to create an animal index you will probably have the abstract Bird which tells what you need to basically include in a bird's description. But you don't describe it by itself.

In your case, both diagrams are "correct" in general. It just depends on the context you did not explain properly. You can fulfill the requirement with both since there is no requirement that you may not instantiate Bird.

Upvotes: 1

Related Questions