ADVANCED DATABASE CONCEPTS Unified Modeling Language Susan D. Urban and Suzanne W. Dietrich

Unified Modeling Language © 2002 by Dietrich and Urban

1

ADVANCED DATABASE CONCEPTS

Unified Modeling Language

Susan D. Urban and Suzanne W. DietrichDepartment of Computer Science and Engineering

Arizona State University Tempe, AZ 85287-5406


2

OUTLINE

• Introduction to the UML standard.• Comparison of UML and EER terminology.• Overview of UML class diagrams.

– Classes– Generalization and Specialization– Abstract Classes– Associations– Association Classes and Reified Associations– Navigability– Aggregation and Composition– Qualified Associations– Xor Constraints– Realization and Interfaces


3

UNIFIED MODELING LANGUAGE • The Unified Modeling Language (UML) is a standard

modeling language for object-oriented analysis and design.• UML represents an integration of several analysis and

design techniques.– Booch's Object-Oriented Notation – Rumbaugh's Object Management Technique – Jacobson's Object-Oriented Software Engineering Notation

• UML is part of the Object Management Group (OMG) standardization effort.


4

EXAMPLES OF UML DIAGRAM TYPES • class diagrams - describes the types of objects and the

relationship between objects. • interaction diagrams - describes the collaboration of objects. • package diagrams - groups classes together into higher-level

units of abstraction. • state diagrams - describes the possible states of an object and

the changes in state in response to events. • activity diagrams - describes the tasks that need to be done. • deployment diagrams - describes the physical relationships

between software and hardware components.


5

CLASS DIAGRAMS

• Data modeling in UML involves the use of class diagrams.• Class diagrams are also known as static structural

diagrams.• Class diagrams are similar to EER diagrams, but differ in

several ways:– Class diagrams offer more options for modeling relationships.– In addition to structural relationships, class diagrams support the

modeling of behavior through the specification of operations on classes.


6

UML vs. EER TERMINOLOGY


7

UML CLASS NOTATION

• A UML class specification has three parts:– a class name– a list of attributes, defining the structural aspects of each class

instance– a list of operations, defining the behavioral aspects of each class

instance.• FYI: A class name can be enhanced with a stereotype

enclosed in guillemets («stereotype») above the class name.– A stereotype represents an extension to the UML semantics.– Example: the «persistent» stereotype indicates that a class is to be

implemented as a database object.


8

UML CLASS EXAMPLE


9

OPERATION NAMING CONVENTIONS

• The following operations exist for all attributes:– getAttributeName to query the value of an attribute.– setAttributeName to assign the value of an attribute.

• In addition, the following operations exist for multi-valued attributes:– addAttributeName to add a value to a collection.– removeAttributeName to remove a value from a collection.

• Use other operation names as appropriate according to the semantics of the application.


10

ATTRIBUTE AND OPERATION SPECIFICATIONS

Attributes and operations can be specified at different levels of detail, depending on the status of the design or the specific use of the class diagram.– Attributes and operations can be omitted.– Attributes and operations can be listed by name only.– Attributes and operations can be specified at a greater level of detail.

• [«stereotype»] [visibility] [/] attributeName [multiplicity]: [type] [= initialValue]• [«stereotype»] [visibility] methodName( [parameterList]): [returnType]


11

OPERATION STEREOTYPES

• Operations can also have stereotypes to provide additional details about the functional use of an operation • predefined stereotypes

• «create» - indicates that an operation is a constructor• «destroy» - indicates that an operation is a destructor

• user-defined stereotypes • «standardAccess» - indicates that an operation performs

standard access and modification functions.

• Operation stereotypes are intermixed with operations, grouping operations by functionality.


12

VISIBILITY RULES FOR ATTRIBUTES AND OPERATIONS


13

MISCELLANEOUS NOTATIONAL CONVENTIONS

Notes in the form of dog-eared rectangles can be attached to UML diagrams to provide additional information.


14

GENERALIZATION / SPECIALIZATIONSubclasses are indicated using an open arrow pointing from the subclass to the superclass.

• No semantic difference between separate lines and tree form.• Subclasses are disjoint by default.

Separate arrows Tree form


15

CONSTRAINTS ON SPECIALIZATION

Constraints on specialization are explicitly specified with curly braces ({…}) next to the specialization arrow


16

SPECIALIZATION EXAMPLE


17

ADDITIONAL SPECIALIZATION CONSTRAINTSDiscriminator

• A disjoint specialization can be qualified with the use of a discriminator.

• A discriminator is an pseudoattribute of the superclass that determines membership in the subclass.

• The discriminator is specified as a label on the specialization link and does not appear in the list of attributes for the superclass.

• The superclass is an abstract class (i.e., a class that cannot be directly instantiated).

• Use of a discriminator implies disjoint and mandatory constraints on specialization.


18

DISCRIMINATOR EXAMPLE

Type is a discriminator in the Project hierarchy that determines membership in the FilmProject or ModelingProject class.


19

MULTIPLE DISCRIMINATORS

Multiple discriminators will always result in the use of multiple inheritance involving the discriminator subclasses.


20

ASSOCIATIONSRelationships Between Classes

Associations can have names, role names, and multiplicities.


21

MULTIPLICITIES IN ASSOCIATIONS


22

1:1 ASSOCIATIONS


23

1:N ASSOCIATIONS


24

M:N ASSOCIATIONS


25

ASSOCIATION CLASS • An association class is used when a relationship between

objects has properties. • The models relationship between Model and

ModelingProject is modeled as the Paid association class.


26

• A class can be created to represent a relationship andits attributes when pairs of objects in the relationship forma bag instead of a set.

• Multiplicities must be appropriately adjusted to model the relationship as a class rather than an association class attached to a relationship.

REIFIED ASSOCIATIONSAn Alternative to the Use of Association Classes


27

N-ARY ASSOCIATIONS

• N-ary associations model relationship among three or more classes.

• Lines extending from a diamond are used to connect the classes involved in an n-ary association.

• For a ternary association (A, B, C), the multiplicity on C defines the number of C objects that can be associated with a given (A, B) pair. Comment on this diagram now:


28

REIFICATION OF AN N-ARY ASSOCIATION

• Binary associations are preferred over n-ary associations since they are easier to understand.

• N-ary associations are typically implemented as multiple binary associations.


29

NAVIGABILITY

• Navigability determines the direction in which a relationship can be traversed.

• Binary relationships are by default navigable in both directions.

• An arrow can be added to one end of a binary relationship to indicate that it is uni-directional (i.e., the relationship can only be traversed in one direction).


30

NAVIGABILITY EXAMPLE

• ModelingProject navigates the relationship to access a Sponsor. Correct the arrow below, though.

• Sponsor does not store information about projects sponsored.

• In the Sponsor class, the function getProjectsSponsored can be implemented to determine projectsSponsored.


31

WEAK ENTITIES AS QUALIFIED ASSOCIATIONS

• An employee has many dependents.• An employee has at most one dependent for a given

dependent name.• Every dependent must be related to an employee.


32

THE XOR CONSTRAINT• The {xor} constraint can be used on two or more

associations connected to a single base class to indicate that the instances of the class can only participate in one of the associations.

• The {xor} constraint can be used to simulate the concept of a category from the EER model.• A lower bound of 0 on the base class side - partial category• A lower bound of 1 on the base class side - total category


33

FYI: INTERFACES AND REALIZATION• An interface is class that provides a name to a list of

abstract operations, specifying the behavior that must be implemented in a concrete class.

• The implementation of an interface in a concrete class is referred to as a realization.

• An interface is denoted by «interface» stereotype above the interface name.

• An interface has no attributes and can only have associations with navigation that points into the interface.

• Realization is denoted by a dashed line with an arrow head pointing from the implementation class to the interface class.

• An interface can be a specialization of a higher-level interface.


34

FYI: INTERFACE EXAMPLE


35

FYI: THE INTERFACE ALTERNATIVE TO MULTIPLE INHERITANCE AND CATEGORIES

• A class is a subclass of only one superclass and realizes behavior of an interface class.

• A SelfEmployedPerson is a Person but can exhibit the behavior of a Business entity.


36

HOLLYWOOD UML CLASS DIAGRAM

ADVANCED DATABASE CONCEPTS Unified Modeling Language Susan D. Urban and Suzanne W. Dietrich

Documents

Transcript of ADVANCED DATABASE CONCEPTS Unified Modeling Language Susan D. Urban and Suzanne W. Dietrich