Difference between revisions of "W2561 UML Class Diagrams"
From Coder Merlin
Vyom-nemade (talk | contribs) |
|||
(11 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
[[File:Joy Oil gas station blueprints.jpg|thumb|right|Joy Oil Gas Station Blueprints]] | |||
[[File:Autograph score of the Prague Symphony by Mozart.jpg|thumb|Autograph score of the Prague Symphony by Mozart]] | |||
== Prerequisites == | |||
* [[W1095 Flow Charts]] | |||
== Research == | == Research == | ||
* Read [https://en.wikipedia.org/wiki/Class_diagram Class Diagram (Wikipedia)] | * Read [https://en.wikipedia.org/wiki/Class_diagram Class Diagram (Wikipedia)] | ||
* Read [https://nirajrules.wordpress.com/2011/07/15/association-vs-dependency-vs-aggregation-vs-composition/ (Niraj Bhatt)] | * Read [https://nirajrules.wordpress.com/2011/07/15/association-vs-dependency-vs-aggregation-vs-composition/ (Niraj Bhatt)] | ||
* Watch [https://www.youtube.com/watch?v=UI6lqHOVHic UML Class Diagrams (Lucidchart - YouTube)] | |||
* Read [https://fs.blog/2014/12/counterinsurgency-field-manual/ Counterinsurgency Field Manual (Farnam Street) | |||
== Examples == | |||
=== Dependency === | |||
Alpha ''uses'' Bravo as a parameter to Alpha.f(). A transient relationship exists. | |||
<syntaxhighlight lang="swift"> | |||
class Alpha { | |||
func f(bravo:Bravo) { | |||
bravo.g() | |||
} | |||
} | |||
</syntaxhighlight> | |||
=== Aggregation === | |||
Alpha ''has-a'' Bravo but Bravo's existence is independent of Alpha. | |||
<syntaxhighlight lang="swift"> | |||
class Alpha { | |||
var bravo : Bravo? | |||
init(bravo:Bravo) { | |||
self.bravo = bravo | |||
} | |||
} | |||
</syntaxhighlight> | |||
=== Composition === | |||
Alpha ''has-a'' Bravo and ''owns'' Bravo; Bravo's existence is dependent on Alpha. | |||
<syntaxhighlight lang="swift"> | |||
class Alpha { | |||
let bravo : Bravo | |||
init() { | |||
bravo = Bravo() | |||
} | |||
} | |||
</syntaxhighlight> | |||
== Key Concepts == | == Key Concepts == | ||
[[File:Uml class relation arrows en.svg.png|thumb|UML Class Relation Arrows]] | [[File:Uml class relation arrows en.svg.png|thumb|UML Class Relation Arrows]] | ||
* General | |||
** '''has-a'''/'''part-of''' generally means that one class ''has'' (either through ownership or aggregation) another object | |||
** '''is-a''' generally means that one class ''is'' a subtype of another | |||
** '''can-do-a''' generally means that one class ''can'' perform some function as described by an interface | |||
* '''Class Diagram'''s provide a means for communicating the general, static, conceptual model of an application | * '''Class Diagram'''s provide a means for communicating the general, static, conceptual model of an application | ||
* Classes are represented by a box with with three compartments | * Classes are represented by a box with with three compartments | ||
Line 16: | Line 65: | ||
** '''+''' indicates ''public'' access | ** '''+''' indicates ''public'' access | ||
** '''-''' indicates ''private'' access | ** '''-''' indicates ''private'' access | ||
** '''#''' indicates ''protected'' access | |||
* '''Scope notations''' may be used to specify the scope of attributes and operations | * '''Scope notations''' may be used to specify the scope of attributes and operations | ||
** An underline indicates ''classifier'' (static) scope | ** An underline indicates ''classifier'' (static) scope | ||
Line 28: | Line 78: | ||
**** A '''unidirectional association''' is represented as a solid line with an arrow head pointing in the direction of the association. | **** A '''unidirectional association''' is represented as a solid line with an arrow head pointing in the direction of the association. | ||
**** A '''bidirectional association''' is represented as a solid line between the classes. | **** A '''bidirectional association''' is represented as a solid line between the classes. | ||
**** '''Aggregation''' is a form of ''weak'' association with a | **** '''Aggregation''' is a form of ''weak'' association with a "part-of" relationship, where the contained classes do not have a lifecycle dependency on the container yet are "used" by it. It is represented with a hollow diamond on the containing class with a line drawn to the contained class. | ||
**** '''Composition''' is a form of ''strong'' association where the contained class is "owned" by the container. It is represented as a filled diamond on the containing class with a line drawn to the contained class. | **** '''Composition''' is a form of ''strong'' association where the contained class is "owned" by the container. It is represented as a filled diamond on the containing class with a line drawn to the contained class. | ||
== Exercises == | |||
# Construct a UML diagram (either on paper or electronic tool such as www.draw.io). Be sure to include all ''important'' properties and methods and ensure that relationships between classes are represented correctly. |
Latest revision as of 19:43, 18 August 2021
Within these castle walls be forged Mavens of Computer Science ...
— Merlin, The Coder
Prerequisites[edit]
Research[edit]
- Read Class Diagram (Wikipedia)
- Read (Niraj Bhatt)
- Watch UML Class Diagrams (Lucidchart - YouTube)
- Read [https://fs.blog/2014/12/counterinsurgency-field-manual/ Counterinsurgency Field Manual (Farnam Street)
Examples[edit]
Dependency[edit]
Alpha uses Bravo as a parameter to Alpha.f(). A transient relationship exists.
class Alpha {
func f(bravo:Bravo) {
bravo.g()
}
}
Aggregation[edit]
Alpha has-a Bravo but Bravo's existence is independent of Alpha.
class Alpha {
var bravo : Bravo?
init(bravo:Bravo) {
self.bravo = bravo
}
}
Composition[edit]
Alpha has-a Bravo and owns Bravo; Bravo's existence is dependent on Alpha.
class Alpha {
let bravo : Bravo
init() {
bravo = Bravo()
}
}
Key Concepts[edit]
- General
- has-a/part-of generally means that one class has (either through ownership or aggregation) another object
- is-a generally means that one class is a subtype of another
- can-do-a generally means that one class can perform some function as described by an interface
- Class Diagrams provide a means for communicating the general, static, conceptual model of an application
- Classes are represented by a box with with three compartments
- The top compartment contains the name of the class, capitalized and centered
- The middle compartment contains the attributes (properties) of the class, left-aligned in camel case
- The bottom compartment contains the operations (methods) of the class, left-aligned in camel case
- Abstract operations are indicated by using italics for the operation name
- An abstract class is indicated by using italics for the class name
- Visibility notations may be placed in front of the attributes and operations
- + indicates public access
- - indicates private access
- # indicates protected access
- Scope notations may be used to specify the scope of attributes and operations
- An underline indicates classifier (static) scope
- The lack of an underline indicates instance scope
- A relationship describes logical connections between entities
- Class-Level relationships
- Inheritance indicates that one of the classes is a specialized form (subclass) of the other (superclass). This is also known as an is a relationship, e.g. "a dog is a mammal". This is indicated on a diagram by drawing a line from the subclass to the superclass with a hollow triangle on the superclass end.
- Realization indicates that one of the classes (the client) realizes (implements) the behavior specified by the other class (the supplier or interface). This is indicated on the diagram by drawing a dashed line from the client to the interface with a hollow triangle on the interface end. The interface itself has an <<interface>> tag above the "class" name.
- Instance-Level relationships
- A dependency represents a semantic relationship between two elements. It is represented as a dashed line with an arrow head pointing in the direction of the dependency. Note that actual interaction may be transient and limited to a class reference as an argument to a method.
- An association represents a tighter link than a dependency when the relationship generally exists throughout the lifetime of the class as a reference to another class.
- A unidirectional association is represented as a solid line with an arrow head pointing in the direction of the association.
- A bidirectional association is represented as a solid line between the classes.
- Aggregation is a form of weak association with a "part-of" relationship, where the contained classes do not have a lifecycle dependency on the container yet are "used" by it. It is represented with a hollow diamond on the containing class with a line drawn to the contained class.
- Composition is a form of strong association where the contained class is "owned" by the container. It is represented as a filled diamond on the containing class with a line drawn to the contained class.
- Class-Level relationships
Exercises[edit]
- Construct a UML diagram (either on paper or electronic tool such as www.draw.io). Be sure to include all important properties and methods and ensure that relationships between classes are represented correctly.