CODEWITHSUNDEEP
javaumlaggregationclass-diagrammultiplicity
Eric Saboia
Eric Saboia

Reputation: 321

Multiplicity and aggregation in abstract class

Can I do aggregation between an abstract class and a concret class?.

Example:

Concrete class: Enterprise
- int cod;
- String name;
- List<Office> listoffice;
//methods

Abstract class: Office
- int cod;
- String name;
- List<Enterprise> listenterprise;
//Methods

Remembering, Office class will have a concrete class to instance object with inheritance later.

Upvotes: 3

Views: 1800

Answers (2)

qwerty_so
qwerty_so

Reputation: 36295

Section 9.2 Classifiers of the UML 2.5 spec states

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 basically, if you have a concrete class aggregating abstract classes, you can instantiate the class itself, but none of its aggregated classes. That seems pretty much pointless.

Vice versa, if an abstract class aggregates concrete classes you still have an abstract class. That would be fine.

Upvotes: 2

davidxxx
davidxxx

Reputation: 131326

Here, I suppose that Enterprise is the owner of the aggregation relation and Office is the target of the relation.

In UML, nothing prevents you from doing an aggregation between an abstract class and a concrete class.
You should do that aggregation if conceptually, all concrete sub-classes of Office are also the targets of the aggregation of Enterprise class. You should do that because it factorizes these relations and it brings information that you don't need to repeat for each concrete Office subclass.

However, if conceptually, it exists at least one concrete subclass of Office which may not be the target of the aggregation from Enterprise, don't use the aggregation with as target the abstract class because otherwise your model would be inaccurate.

Upvotes: 2

Related Questions