advanced database concepts unified modeling language susan d. urban and suzanne w. dietrich
DESCRIPTION
ADVANCED DATABASE CONCEPTS Unified Modeling Language Susan D. Urban and Suzanne W. Dietrich Department of Computer Science and Engineering Arizona State University Tempe, AZ 85287-5406 . OUTLINE. • Introduction to the UML standard. •Comparison of UML and EER terminology. - PowerPoint PPT PresentationTRANSCRIPT
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
Unified Modeling Language © 2002 by Dietrich and Urban
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
Unified Modeling Language © 2002 by Dietrich and Urban
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.
Unified Modeling Language © 2002 by Dietrich and Urban
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.
Unified Modeling Language © 2002 by Dietrich and Urban
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.
Unified Modeling Language © 2002 by Dietrich and Urban
6
UML vs. EER TERMINOLOGY
Unified Modeling Language © 2002 by Dietrich and Urban
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.
Unified Modeling Language © 2002 by Dietrich and Urban
8
UML CLASS EXAMPLE
Unified Modeling Language © 2002 by Dietrich and Urban
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.
Unified Modeling Language © 2002 by Dietrich and Urban
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]
Unified Modeling Language © 2002 by Dietrich and Urban
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.
Unified Modeling Language © 2002 by Dietrich and Urban
12
VISIBILITY RULES FOR ATTRIBUTES AND OPERATIONS
Unified Modeling Language © 2002 by Dietrich and Urban
13
MISCELLANEOUS NOTATIONAL CONVENTIONS
Notes in the form of dog-eared rectangles can be attached to UML diagrams to provide additional information.
Unified Modeling Language © 2002 by Dietrich and Urban
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
Unified Modeling Language © 2002 by Dietrich and Urban
15
CONSTRAINTS ON SPECIALIZATION
Constraints on specialization are explicitly specified with curly braces ({…}) next to the specialization arrow
Unified Modeling Language © 2002 by Dietrich and Urban
16
SPECIALIZATION EXAMPLE
Unified Modeling Language © 2002 by Dietrich and Urban
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.
Unified Modeling Language © 2002 by Dietrich and Urban
18
DISCRIMINATOR EXAMPLE
Type is a discriminator in the Project hierarchy that determines membership in the FilmProject or ModelingProject class.
Unified Modeling Language © 2002 by Dietrich and Urban
19
MULTIPLE DISCRIMINATORS
Multiple discriminators will always result in the use of multiple inheritance involving the discriminator subclasses.
Unified Modeling Language © 2002 by Dietrich and Urban
20
ASSOCIATIONSRelationships Between Classes
Associations can have names, role names, and multiplicities.
Unified Modeling Language © 2002 by Dietrich and Urban
21
MULTIPLICITIES IN ASSOCIATIONS
Unified Modeling Language © 2002 by Dietrich and Urban
22
1:1 ASSOCIATIONS
Unified Modeling Language © 2002 by Dietrich and Urban
23
1:N ASSOCIATIONS
Unified Modeling Language © 2002 by Dietrich and Urban
24
M:N ASSOCIATIONS
Unified Modeling Language © 2002 by Dietrich and Urban
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.
Unified Modeling Language © 2002 by Dietrich and Urban
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
Unified Modeling Language © 2002 by Dietrich and Urban
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:
Unified Modeling Language © 2002 by Dietrich and Urban
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.
Unified Modeling Language © 2002 by Dietrich and Urban
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).
Unified Modeling Language © 2002 by Dietrich and Urban
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.
Unified Modeling Language © 2002 by Dietrich and Urban
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.
Unified Modeling Language © 2002 by Dietrich and Urban
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
Unified Modeling Language © 2002 by Dietrich and Urban
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.
Unified Modeling Language © 2002 by Dietrich and Urban
34
FYI: INTERFACE EXAMPLE
Unified Modeling Language © 2002 by Dietrich and Urban
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.
Unified Modeling Language © 2002 by Dietrich and Urban
36
HOLLYWOOD UML CLASS DIAGRAM