(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 o Painter Sculptor Person d Man Woman

Equivalent UML-diagram AMIS notation: Artist No notation for overlapping versus disjoint. Black triangle denotes total (complete) specialisation Painter Sculptor Person Additional methodological advice given in AMIS-course: Always work with disjoint subclasses Man Woman

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 o Motorcycle Car Boat Three-wheel v. Amphibious v.

Set theoretical view of this example Vehicle Motor Car Boat cycle Three wheel vehicle Amphibious vehicle

UML model with disjount subclasses & single inheritance Vehicle Motorcycle Three-wheel v. Car Amphibious v. Boat 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 objects 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 u Account- 0..M 1..N Bank holder

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

Set theoretical perspective Typical case : - Person & Company are disjoint sets and - Account holder equals union of Person & Company Company Person Account Holder

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 1..M 0..N Consultant Project Participation 1..M 1..1 Contract

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 of 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 object has responsibility for the existence and storage of the composed objects (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 of 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.