1 / 55

COP 3503 FALL 2012 Shayan Javed Lecture 9

COP 3503 FALL 2012 Shayan Javed Lecture 9. Programming Fundamentals using Java. UML Diagrams. UML. U nified M odeling L anguage. UML. U nified M odeling L anguage Goal: Common language for creating models of Object-Oriented software. UML. U nified M odeling L anguage Goal:

carson
Télécharger la présentation

COP 3503 FALL 2012 Shayan Javed Lecture 9

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. COP 3503 FALL 2012ShayanJavedLecture 9 Programming Fundamentals using Java

  2. UML Diagrams

  3. UML • Unified Modeling Language

  4. UML • Unified Modeling Language • Goal: • Common language for creating models of Object-Oriented software

  5. UML • Unified Modeling Language • Goal: • Common language for creating models of Object-Oriented software • Two aspects: • Class Diagrams (Static design): Classes, Attributes, Relationships

  6. UML • Unified Modeling Language • Goal: • Common language for creating models of Object-Oriented software • Two aspects: • Class Diagrams (Static design): Classes, Attributes, Relationships • Dynamic design: Objects, messages, finite state machines [Sequence/Activity/State Machine diagrams]

  7. Class Diagrams • Depict classes within a model

  8. Class Diagrams • Depict classes within a model • Classes have: • Attributes (Properties/Member Variables)

  9. Class Diagrams • Depict classes within a model • Classes have: • Attributes (Properties/Member Variables) • Operations (Functions/Methods)

  10. Class Diagrams • Depict classes within a model • Classes have: • Attributes (Properties/Member Variables) • Operations (Functions/Methods) • Relationships with other classes

  11. Class Diagrams Class Properties Methods()

  12. Class Diagrams GeometricObject color : String name : String area : double GeometricObject() GeometricObject(String, String) get() : String/double set(..) : void

  13. Class Diagrams • Properties • name : type

  14. Class Diagrams • Properties • name : type • Ex.: • area : double

  15. Class Diagrams • Methods: • name(parameters) : return type

  16. Class Diagrams • Methods: • name(parameters) : return type • Ex.: • getArea( ) : double

  17. Class Diagrams • Methods: • name(parameters) : return type • Ex.: • getArea( ) : double • setColor(color : String) : void

  18. Class Diagrams • Properties/Methods can be public/private/protected/static

  19. Class Diagrams • Properties/Methods can be public/private/protected/static • Need a way to indicate that somehow

  20. Class Diagrams • Properties/Methods can be public/private/protected/static • Need a way to indicate that somehow • Add a sign next to the property/method: • Public (+)

  21. Class Diagrams • Properties/Methods can be public/private/protected/static • Need a way to indicate that somehow • Add a sign next to the property/method: • Public (+) • Private (-)

  22. Class Diagrams • Properties/Methods can be public/private/protected/static • Need a way to indicate that somehow • Add a sign next to the property/method: • Public (+) • Private (-) • Protected(#)

  23. Class Diagrams • Properties/Methods can be public/private/protected/static • Need a way to indicate that somehow • Add a sign next to the property/method: • Public (+) • Private (-) • Protected(#) • To indicate a static property/method, underline it

  24. Class Diagrams • Final (constant) properties are declared by writing them in ALL_CAPS • (Math.PI for example)

  25. Class Diagrams GeometricObject # Color : String # name : String # area : double + GeometricObject() + GeometricObject(String, String) + get() : String/double + set(..) : void

  26. Class Diagrams • But GeometricObject is abstract

  27. Class Diagrams • But GeometricObject is abstract • How do you differentiate between an abstract and non-abstract class/method?

  28. Class Diagrams • But GeometricObject is abstract • How do you differentiate between an abstract and non-abstract class/method? • Italicize it

  29. Class Diagrams GeometricObject # Color : String # name : String # area : double + GeometricObject() + GeometricObject(String, String) + get() : String/double + set(..) : void + getArea() : double

  30. Class Diagrams • But can’t italicize when writing...

  31. Class Diagrams • But can’t italicize when writing... • So to indicate abstract methods/classes on paper write {abstract} in brackets

  32. Class Diagrams GeometricObject {abstract} # Color : String # name : String # area : double + GeometricObject() + GeometricObject(String, String) + get() : String/double + set(..) : void + getArea() : double {abstract}

  33. Class Diagrams • Relationships between classes: • Generalization (Inheritance = “is a”)

  34. Class Diagrams • Relationships between classes: • Generalization (Inheritance = “is a”) • Aggregation (“has a”)

  35. Class Diagrams • Relationships between classes: • Generalization (Inheritance = “is a”) • Aggregation (“has a”) • Composition (“owns a”)

  36. Class Diagrams • Generalization (Inheritance - “is a”): Circle - radius : double + Circle (...) + getRadius( ) : double + getArea( ) : double + setRadius(radius : double) : void

  37. Class Diagrams • Generalization (Inheritance - “is a”): Circle GeometricObject

  38. Class Diagrams • Generalization (Inheritance - “is a”): • Used to indicate inheritance relationship

  39. Class Diagrams • Generalization (Inheritance - “is a”): Circle Rectangle GeometricObject

  40. Class Diagrams • Aggregation (“has a”):

  41. Class Diagrams • Aggregation (“has a”): • Class1 has a number of Class2

  42. Class Diagrams • Aggregation (“has a”): • Class1 has a number of Class2 • Course has a number of Students • Course has manyStudents

  43. Class Diagrams • Aggregation (“has a”): public Course { Student[] students = newStudent[capacity]; }

  44. Class Diagrams • Aggregation (“has a”): public Course { Student[] students = newStudent[capacity]; } Student Course 0..capacity students

  45. Class Diagrams • Aggregation (“has a”): • 0...capacity = number of students in the Course • “students” = the variable

  46. Class Diagrams • Aggregation (“has a”): • 0...capacity = number of students in the Course • “students” = the variable • So aggregation indicated by empty diamond

  47. Class Diagrams • Composition (“owns a”):

  48. Class Diagrams • Composition (“owns a”): • Similar to Aggregation – but one class completely depends on the other.

  49. Class Diagrams • Composition (“owns a”): • Similar to Aggregation – but one class completely depends on the other. • Destroying one also destroys the dependent class

  50. Class Diagrams • Composition (“owns a”): Wheels Car 4 wheels

More Related