1. PRJ566: PROJECT PLANNING AND MANAGEMENT Class Diagrams

2. Class Design  Analysis objects are things in the real world, e.g invoice, registration form, sales person  Design objects are logical constructs which may map to objects in the real world but which find their existence only in code

3. Transformation  Is the process of turning real world domain abstraction into an object in the model.  Every significant object in the domain analysis is a candidate for being transformed into one or more design objects (Noun Filter)

4. Class Diagrams  A class diagram shows the existence of classes and their relationships in the logical view of a system  UML modeling elements in class diagrams Classes and their structure and behavior Association, aggregation, and inheritance relationships Multiplicity and navigation indicators

5. Copyright © 1997 by Rational Software Corporation Relationships  Relationships provide a pathway for communication between objects  Sequence and/or collaboration diagrams are examined to determine what links between objects need to exist to accomplish the behavior -- if two objects need to “talk” there must be a link between them  Types of relationships are: Association Aggregation

6. Copyright © 1997 by Rational Software Corporation Relationships  An association is a bi-directional connection between classes An association is shown as a line connecting the related classes  An aggregation is a stronger form of relationship where the relationship is between a whole and its parts An aggregation is shown as a line connecting the related classes with a diamond next to the class representing the whole

7. Copyright © 1997 by Rational Software Corporation Registration Manager Math 101: Course 3: add student(joe) RegistrationManager Course Finding Association Relationships  Relationships are discovered by examining interaction diagrams If two objects must “talk” there must be a pathway for communication

8. Copyright © 1997 by Rational Software Corporation Multiplicity and Navigation  Multiplicity defines how many objects participate in a relationships Multiplicity is the number of instances of one class related to ONE instance of the other class For each association and aggregation, there are two multiplicity decisions to make: one for each end of the relationship

9. Aggregations An aggregation is  a special kind of association  the composition of a set of parts—a whole- part relationship  a “has a” or “consists of” relationship

10. Aggregations Examples:  An invoice has invoice items  A company has contacts

11. Aggregate Class Component Class Aggregation Symbol

12. Proxy  Is an object in the design which represents key aspects of a real world entity Also called a surrogate  First create proxy for all the actors in the system, e.g. customer, guest  Then for many of the real world objects, e.g, invoice, receipt, reservation

13. Aggregations Essential property  The aggregate (Invoice) acts as a proxy for its parts (InvoiceItem)  This means the aggregate takes on operations which are then propagated to the individual parts. (These operations don’t necessarily cause a change in the aggregate itself.)

14. Here adding a ContactPerson does not change the proxy (Company).

15. Here adding an InvoiceItem does change the proxy (Invoice). Its totals are updated.

16. Aggregations Aggregation vs Association  In contrast to the association, the involved classes do not maintain an equal relationship but the aggregate class assumes a special role for delegation of responsibility and leadership

17. Multiplicity in Aggregation  Generally a 1:M relationship The aggregate will be the 1 The parts will be the many 1…n

18. Aggregation  Can describe a relationship where the parts are existence-dependent on the whole. If the whole is deleted, the individual parts will be deleted. If an individual part is deleted, the aggregate will survive.

19. Composition Composition is a strict form of aggregation.  The life of the parts is subordinate to the whole. The parts are generated together with the aggregate or later. Parts are destroyed before the whole

20. Composition  The component parts depend on the aggregate for existence—delete the aggregate and the components disappear (this is called a cascading delete)

21. Composition Which of these might be composition?  An invoice has invoice items  A company has contacts  A catalogue has catalogue items  An MSWord document style has a font, a language, a paragraph control, and so on…

22. When we delete Invoice, does InvoiceItem disappear? Yes! It has no meaning without Invoice. To indicate a composition, the diamond is coloured black.

23. When we delete Company, does ContactPerson disappear? Yes! It has no meaning without Company.

24. When about Catalogue and CatalogueItem? If CatalogueItem belongs to only one catalogue and it is the intersection between that Catalogue and an Item then yes, it would disappear if Catalogue were deleted and we would have a composition relationship. But note the Item itself would not disappear!

25. This sequence diagram shows the proxy relationship of Catalogue to CatalogueItem

26. This sequence diagram shows an example of the cascading delete that identifies Composition.

27. Aggregations Aggregation vs Association  Useful in modeling—an aggregation shows where there is higher binding between classes which in turn makes models easier to understand  Aggregation helps determine implementation (e.g. arrays, etc.)  When in doubt use an association

28. Copyright © 1997 by Rational Software Corporation Inheritance  Inheritance is a relationships between a base class and its derived classes  There are two ways to find inheritance: Generalization Specialization  Common attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy

29. Inheritance  Generalization Identify similar structure and behaviour among classes  Specialization Identify a parent class--how can it be “specialized” for use in other parts of the system?

30. Inheritance  Inheritance is a “generalization” relationship  The base class (parent class, super class) carries a certain set of characteristics (attributes, operations, relationships)  The derived classes (child classes, sub classes) inherit those characteristics plus they have some of their own

31. Inheritance  A child class “is a” special type of the more general parent class  E.g. “A video is a type of library item” “A part-time student is a type of student” “A reserve item screen is a type of library screen”

32. Why Inheritance? Why do we care about inheritance?  Less duplication  More reusability  More standardization  Less change impact  Classes are more focused

33. Inheritance  Structures showing inheritance are called Inheritance Hierarchies

34. How do you find inheritance?  Look for classes that share many operations, attributes (But be careful! Don’t create false inheritance!)  Look for actions or text (i.e. in specs) that imply that there are several types of objects in a class--investigate further.

35. Copyright © 1997 by Rational Software Corporation Inheritance Generalization The capability to create base classes that encapsulate structure and behaviour common to several classes.

36. Inheritance Generalization:  Here we see similar structure and behaviour among classes

37. Inheritance Generalization:  Now we create a parent class

38. Inheritance Generalization:  Now we move all common elements from children to parent and we draw the inheritance relationship

39. Copyright © 1997 by Rational Software Corporation Inheritance Specialization The ability to create derived classes that represent refinements to the base class—typically structure and behaviour are added to the new derived class.

40. Inheritance  In Rational Rose you need to set Parent attributes as PROTECTED instead of private

41. Inheritance  You will see the inherited operations and attributes only in the specification window not in class diagrams

42. Inheritance  A critical aspect of public inheritance is that it should model specialization/ generalization and nothing else.

43. Base Classes and Derived Classes  Derived classes must know who their base class is, and they depend on their base class.  Base classes should know nothing about their derived classes.

44. Class Design  Build the inheritance hierarchy  Map use cases to object interaction  Delegate every responsibility of the system to a specific object  Fully understand the collaboration between objects  Create a blueprint for your implementation