1. Unified Modeling Language © 2002 by Dietrich and Urban1 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. Unified Modeling Language © 2002 by Dietrich and Urban2 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 © 2002 by Dietrich and Urban3 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. Unified Modeling Language © 2002 by Dietrich and Urban4 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. Unified Modeling Language © 2002 by Dietrich and Urban5 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. Unified Modeling Language © 2002 by Dietrich and Urban6 UML vs. EER TERMINOLOGY

7. Unified Modeling Language © 2002 by Dietrich and Urban7 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. Unified Modeling Language © 2002 by Dietrich and Urban8 UML CLASS EXAMPLE

9. Unified Modeling Language © 2002 by Dietrich and Urban9 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. Unified Modeling Language © 2002 by Dietrich and Urban10 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. Unified Modeling Language © 2002 by Dietrich and Urban11 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. Unified Modeling Language © 2002 by Dietrich and Urban12 VISIBILITY RULES FOR ATTRIBUTES AND OPERATIONS

13. Unified Modeling Language © 2002 by Dietrich and Urban13 MISCELLANEOUS NOTATIONAL CONVENTIONS Notes in the form of dog-eared rectangles can be attached to UML diagrams to provide additional information.

14. Unified Modeling Language © 2002 by Dietrich and Urban14 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 arrowsTree form

15. Unified Modeling Language © 2002 by Dietrich and Urban15 CONSTRAINTS ON SPECIALIZATION Constraints on specialization are explicitly specified with curly braces ({…}) next to the specialization arrow

16. Unified Modeling Language © 2002 by Dietrich and Urban16 SPECIALIZATION EXAMPLE

17. Unified Modeling Language © 2002 by Dietrich and Urban17 ADDITIONAL SPECIALIZATION CONSTRAINTS Discriminator 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. Unified Modeling Language © 2002 by Dietrich and Urban18 DISCRIMINATOR EXAMPLE Type is a discriminator in the Project hierarchy that determines membership in the FilmProject or ModelingProject class.

19. Unified Modeling Language © 2002 by Dietrich and Urban19 MULTIPLE DISCRIMINATORS Multiple discriminators will always result in the use of multiple inheritance involving the discriminator subclasses.

20. Unified Modeling Language © 2002 by Dietrich and Urban20 ASSOCIATIONS Relationships Between Classes Associations can have names, role names, and multiplicities.

21. Unified Modeling Language © 2002 by Dietrich and Urban21 MULTIPLICITIES IN ASSOCIATIONS

22. Unified Modeling Language © 2002 by Dietrich and Urban22 1:1 ASSOCIATIONS

23. Unified Modeling Language © 2002 by Dietrich and Urban23 1:N ASSOCIATIONS

24. Unified Modeling Language © 2002 by Dietrich and Urban24 M:N ASSOCIATIONS

25. Unified Modeling Language © 2002 by Dietrich and Urban25 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. Unified Modeling Language © 2002 by Dietrich and Urban26 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. REIFIED ASSOCIATIONS An Alternative to the Use of Association Classes

27. Unified Modeling Language © 2002 by Dietrich and Urban27 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. Unified Modeling Language © 2002 by Dietrich and Urban28 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. Unified Modeling Language © 2002 by Dietrich and Urban29 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. Unified Modeling Language © 2002 by Dietrich and Urban30 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. Unified Modeling Language © 2002 by Dietrich and Urban31 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. Unified Modeling Language © 2002 by Dietrich and Urban32 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. Unified Modeling Language © 2002 by Dietrich and Urban33 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. Unified Modeling Language © 2002 by Dietrich and Urban34 FYI: INTERFACE EXAMPLE

35. Unified Modeling Language © 2002 by Dietrich and Urban35 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. Unified Modeling Language © 2002 by Dietrich and Urban36 HOLLYWOOD UML CLASS DIAGRAM