(E)ER versus UML Architecture & Modelling of MIS Comparing - - PowerPoint PPT Presentation

(E)ER versus UML

Architecture & Modelling of MIS

• Comparing EER to UML notation
• Additional methodological

considerations given in AMMIS

EER-diagram: Characteristics of a specialisation

Artist Painter Sculptor

• Person

Man Woman

d

Equivalent UML-diagram

Artist Painter Sculptor Person Man Woman

Additional methodological advice given in AMIS-course: Always work with disjoint subclasses AMIS notation: No notation for overlapping versus disjoint. Black triangle denotes total (complete) specialisation

Specialisation hierarchy or lattice, multiple inheritance

• A specialisation can be several levels deep. Moreover, if you have the

constraint that every subclass can have only a single superclass, you get a specialisation hierarchy. In the other case, you get a specialisation lattice.

• The concept where a shared subclass (i.e. a subclass with multiple

parents) inherits from all of these parents is called multiple inheritance.

• ....

Additional methodological advice given in AMIS-course: Always work with single superclass (single inheritance), even though UML notation allows for multiple inheritance

EER Specialisation lattice: example

Vehicle Motorcycle Boat

• Car

Amphibious v. Three-wheel v.

Set theoretical view of this example

Motor cycle Car Boat Three wheel vehicle Amphibious vehicle Vehicle

UML model with disjount subclasses & single inheritance

Vehicle Motorcycle Boat Car Amphibious v. Three-wheel v. This model does not exploit commonalities between cars & three wheel vehicles or between motor cycle and three wheel vehicle. (and between car and amphibious vehicle, and between boat and amphibious vehicle) Motivation from a methodological point of view is the requirement that a model should be easy to translate to (OO) code and that not all OO programming languages allow for multiple inheritance.

EER: Categorisation

• A category is a subclass that has several possible
• superclasses. Each superclass represents a different

entity type. The category represents a collection of

• bjects that is a subset of the union of the

superclasses.

• Inheritance in the case of categorisation

corresponds to an entity inheriting only the attributes and relationship types of that superclass it is a member of (selective inheritance).

• A categorisation can be total or partial.
• Note: a total categorisation can also be

represented as a specialisation/generalisation

EER-diagram: categorisation

Person Company Account- holder Bank u 1..N 0..M

Set theoretical perspective

Person Company Account Holder General case, according to EER definition of categorisation

Set theoretical perspective

Person Company Account Holder Typical case:

• Person & Company are disjoint sets and
• Account holder equals union of Person & Company

UML: categoristation

• UML has no equivalent to categorisation
• Typical case is an example of total categorisation and can thus

be represented as generalisation/specialisation.

• So, typical case on previous slide can be modelled as

Account Holder Person Company

EER: Aggregation

• Aggregation: the entity types that are related

by a particular relationship are combined into a higher-level composite entity type.

• Aggregating entity types is useful when the

composite entity type is in itself to be related to another entity type.

EER: Aggregation

Project

0..N 1..M

Consultant Participation Contract

1..M 1..1

UML Aggregation

• In UML an aggregation is an association between two classes

that may carry the notion of "composition".

• As a result, the word "Aggregation" has totally different

meanings in EER and UML.

• UML discerns between

– shared aggregation (white diamond)

• Indicates that the property has a shared aggregation. Precise semantics
• f shared aggregation varies by application area and modeler. The order

and way in which part instances are created is not defined.

– composite Aggregation (filled diamond)

• Indicates that the property is aggregated compositely, i.e., the composite
• bject has responsibility for the existence and storage of the composed
• bjects (parts).

UML Composition

• Semantics of Composition (filled diamond)

– An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all

• f its parts are normally deleted with it. Note that a part can (where allowed) be removed from a

composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element. Composition is represented by the isComposite attribute on the part end of the association being set to true.