Comparing EER and UML Architecture for Modelling of MIS
This discussion delves into the comparison between Entity-Relationship (EER) and Unified Modeling Language (UML) architectures for the modelling of Management Information Systems (MIS). It explores the differences in notation, methodological considerations, specialisation hierarchies, and categorisation within both EER and UML frameworks, providing insights on when to apply each approach effectively.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
(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: No notation for overlapping versus disjoint. Artist 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 cycle Car Boat 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- holder 0..M 1..N Bank
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.
