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

1. 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

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 behaviorthrough 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 / SPECIALIZATION Subclasses 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. REIFIED ASSOCIATIONSAn Alternative to the Use of Association Classes • A class can be created to represent a relationship and its attributes when pairs of objects in the relationship form a 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.

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