1 / 17

Class Diagrams

Class diagrams are essential in object-oriented design, representing the structure and relationships within a system. They can be viewed from conceptual, specification, and implementation perspectives. Class diagrams illustrate concepts via classes, showcasing attributes, associations, and multiplicities. It's crucial to differentiate between interfaces and implementations, following the principle of programming to the interface. Associations represent relationships between classes, while multiplicities define the number of instances involved. Understanding these elements enhances the clarity and functionality of your software design.

micah
Télécharger la présentation

Class Diagrams

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Class Diagrams Class Diagrams

  2. Perspectives • Conceptual • classes represent concepts in a domain • software (& language) independent • Specification • classes represent interfaces (or types) • Implementation • full classes • automatic code generation Class Diagrams

  3. Interface vs Implementation • Not well distinguished by current OOP languages • Classes (particularly in C++) combine the two • Design Rule #1 • Program to the interface, not the implementation Class Diagrams

  4. A Class Diagram Class Diagrams

  5. A Class Diagram Associations Class Diagrams

  6. Associations • Relationships between instances of classes • Conceptual perspective  conceptual relation • Specification perspective  responsibility • Implementation imply specifics (e.g. pointers) Associations Class Diagrams

  7. A Class Diagram Generalization Class Diagrams

  8. A Class Diagram Abstract class represented by italicised name Class Diagrams

  9. Multiplicities • Mandatory • At each end • 0..1 • 0..* • 1..* • 1,3,9..11 Multiplicities Class Diagrams

  10. Multiplicities Class Diagrams

  11. Role Names Role Names Class Diagrams

  12. Role Names • Are optional • May go at either (or both) end(s) • Alternatively, association itself may be named • Bleah! • Only name roles when it adds clarity Class Diagrams

  13. Role Names Role Names Class Diagrams

  14. Multiple associations Second association saying department has one head who is a professor (and prof can only be head of one department) Class Diagrams

  15. Directed associations New association is directed, meaning it can only be navigated from department to prof. E.g. department is supposed to know who its head is but prof doesn't have to know he/she is head. Class Diagrams

  16. Direction • No arrowheads means either • directionality is unspecified • navigability is in both directions • I prefer unspecified (except, perhaps in implementation perspective) Class Diagrams

  17. Attributes • What is difference between attribute and association? • Often none • At implementation, association will often imply a pointer from one class to the other • Use attributes for primitive, wholly contained data (integers, strings) Class Diagrams

More Related