0% found this document useful (0 votes)
6 views9 pages

UML_reference

Uploaded by

ShaharSchocron
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views9 pages

UML_reference

Uploaded by

ShaharSchocron
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

Course Notes: UML Class Diagrams for Programmers

https://www.udemy.com/course/uml-class-diagrams-for-programmers
©Riaan Nel

Review: Class Diagrams - Basic Concepts

UML Class Diagrams consists of three sections: the class name, attributes, and operations.

• Class names are written in bold.


• Abstract class names are written in italics.
• Static attributes and operations are underlined.

Attributes refer to the properties, or fields, or a class. They are expressed as follows:

<visibility><name>: <type> = <default value> <{modifier}>

• Visibility refers to the access modifiers on the attributes, and UML supports the
following access modifiers (relate them back to the programming language in which
you will write your code):
o + (public)
o - (private)
o ~ (package)
o # (protected)
• The name of an attribute is used to identify the attribute.
• The type of the attribute refers to the data type that it will use (String, Integer, etc.).
• The default value of an attribute is optional, and may be left blank.
• The modifier is optional, and serves to provide additional information on the
attribute, such as {readOnly}.

Operations refer to the behaviours, or methods of a class. They are expressed as follows:

<visibility><name>(<parameter list>): <return type>

• Visiblity and name are self-explanatory - they serve the same purpose as they do on
attributes.
• The parameters refer to the parameters (or method arguments) that will be passed to
the operation when it is invoked. They are represented as follows: <parameter
name>: <parameter type>

This is a supplement for students of the “UML Class Diagrams for Programmers” course and may not be
redistributed.

If you enjoyed this course and you would like to share it with a friend, please use the referral link:
https://www.udemy.com/course/uml-class-diagrams-for-
programmers/?referralCode=617E1ACA20E360B0E995
Course Notes: UML Class Diagrams for Programmers
https://www.udemy.com/course/uml-class-diagrams-for-programmers
©Riaan Nel

• The return type refers to the type of the result returned by the operation, such as
String or Integer (or void, if it does not return anything).

Review: Class Diagrams - Relationships

Object-oriented classes have relationships between them - they extend each other
(inheritance), they depend on each other (dependency), they interact with each other
(association), or they form part of each other (aggregation and composition).

Relationships also have multiplicity, which shows how many instances of a class can exist
on each side of a relationship.

Dependency relationships exist when classes depend on each other in such a way that a
change to one class may affect the other, such as when one class accepts an instance of
another class as parameter to a method.

• Dependency relationships are represented by arrows on dashed lines. Stereotypes can


be indicated within guillemets to provide further detail on the nature of the
relationship.

• A dependency relationship can exist when we have a Library class that manages Book
objects. Since the Library class has a method that returns a Book, changes to the
Book class could result in changes to the Library class (based on how Book objects
are created).

Generalization relationships exists when one class extends another class (making it a
specialization of the parent class, like a Car is a specialization of a Vehicle).

This is a supplement for students of the “UML Class Diagrams for Programmers” course and may not be
redistributed.

If you enjoyed this course and you would like to share it with a friend, please use the referral link:
https://www.udemy.com/course/uml-class-diagrams-for-
programmers/?referralCode=617E1ACA20E360B0E995
Course Notes: UML Class Diagrams for Programmers
https://www.udemy.com/course/uml-class-diagrams-for-programmers
©Riaan Nel

• Generalization relationships are represented by a triangular arrow on a solid line.

• Operations and attributes on the parent class also exist on the child classes, without
being explicitly specified.
• A generalization relationship can exist when we have a system that keeps track of
vehicle rentals, where we have various specialized vehicles.

Association relationships often exist when classes have variables of other types, that they can
invoke operations on.

• Association relationships are represented by an arrow on a solid line.

• Association relationships can be bi-directional, in which case both classes can


reference each other.

This is a supplement for students of the “UML Class Diagrams for Programmers” course and may not be
redistributed.

If you enjoyed this course and you would like to share it with a friend, please use the referral link:
https://www.udemy.com/course/uml-class-diagrams-for-
programmers/?referralCode=617E1ACA20E360B0E995
Course Notes: UML Class Diagrams for Programmers
https://www.udemy.com/course/uml-class-diagrams-for-programmers
©Riaan Nel

• Association relationships can also include multiplicity, where we can have one
instance on one side and exactly zero or one instance on the other side, or one
instance on one side zero or more instances on the other side (* refers to any number
of instances), or any other combination.

• An association relationship can exist when we model the relationship between doctors
and patients, where a doctor can have any number of patients and a patient can only
be treated by one doctor at a time.

Aggregation relationships exist when we aggregate (or bring together) objects of one class
in another class.

• Aggregation relationships are represented by an unfilled diagram on the 'owning' side


of the relationship.

This is a supplement for students of the “UML Class Diagrams for Programmers” course and may not be
redistributed.

If you enjoyed this course and you would like to share it with a friend, please use the referral link:
https://www.udemy.com/course/uml-class-diagrams-for-
programmers/?referralCode=617E1ACA20E360B0E995
Course Notes: UML Class Diagrams for Programmers
https://www.udemy.com/course/uml-class-diagrams-for-programmers
©Riaan Nel

• Objects on both sides of an aggregation relationship can exist in isolation.


• Aggregation relationships can have multiplicity.
• An association relationship can exist when we model teams and players. A player can
exist without belonging to a team, and a team can exist without any players.

Composition relationships when objects are composed of (or made up of) other objects.

• Composition relationships are represented by a filled diamond on the 'owning' side.

• Objects in a composition relationship cannot, conceptually, exist in isolation. This


isn't always easy to enforce in code.
• If the parent object in a composition relationship is destroyed, so are the child objects.
• A composition relationship can exist when we model a system for creating web pages
- pages cannot exist without a page header and a page body, and each PageHeader and
PageBody object must belong to a WebPage object.

This is a supplement for students of the “UML Class Diagrams for Programmers” course and may not be
redistributed.

If you enjoyed this course and you would like to share it with a friend, please use the referral link:
https://www.udemy.com/course/uml-class-diagrams-for-
programmers/?referralCode=617E1ACA20E360B0E995
Course Notes: UML Class Diagrams for Programmers
https://www.udemy.com/course/uml-class-diagrams-for-programmers
©Riaan Nel

Review: Class Diagrams - Advanced Concepts

Notes are used to add additional information to UML Class Diagrams (and other
UML diagrams).

• Notes are represented by a rectangle with the top-right corner folded over.
• Notes can exist on the diagram itself, or they can be linked to specific elements with a
dashed line.

Template classes are parameterized to operate on specific types.

• Template classes are represented by a generic type in a dashed block on the top-right
corner of the class.
• Template classes correspond to generic classes in languages like Java and C#.
This is a supplement for students of the “UML Class Diagrams for Programmers” course and may not be
redistributed.

If you enjoyed this course and you would like to share it with a friend, please use the referral link:
https://www.udemy.com/course/uml-class-diagrams-for-
programmers/?referralCode=617E1ACA20E360B0E995
Course Notes: UML Class Diagrams for Programmers
https://www.udemy.com/course/uml-class-diagrams-for-programmers
©Riaan Nel

• A template class can be used to represent a Container class that can hold objects of a
specific type.

Derived attributes are class attributes that can be calculated based on other values on a class
(or outside of it, such as the current date).

• Derived attributes are indicated by a forward slash (/) preceding the attribute name
(e.g. /age: int ).
• We can use notes to indicate how derived attributes are calculated (although we could
also show this on a sequence- or activity diagram).
• We can use a derived attribute to model a class that calculates a customer's age.

Keywords are used to provide additional metadata on a class or class element.

• Keywords on a class (the ones that we use in this course) are indicated in guillemets.

Constructors are special operations used to create instances of a class.

• Constructors share the name of the class and do not specify a return type.
• Constructors can be indicated with the 'constructor' keyword.

This is a supplement for students of the “UML Class Diagrams for Programmers” course and may not be
redistributed.

If you enjoyed this course and you would like to share it with a friend, please use the referral link:
https://www.udemy.com/course/uml-class-diagrams-for-
programmers/?referralCode=617E1ACA20E360B0E995
Course Notes: UML Class Diagrams for Programmers
https://www.udemy.com/course/uml-class-diagrams-for-programmers
©Riaan Nel

• Constructors can also be indicated without the 'constructor' keyword, since one can
easily infer that an operation is a constructor.

Review: Interfaces and Enumerations

Interfaces define contracts for behaviour, but without implementing that behaviour.

• Interfaces are realized (or implemented) by concrete classes.


• Interfaces are indicated by the 'interface' keyword.
• Realization is shown with a triangle on a dashed line.
• Interface methods are implicitly included on classes that realize an interface, even if
they are not shown.

Enumerations, or enums, are classes that provide a fixed set of literal values.

• Enums are indicated by the 'enumeration' keyword.


This is a supplement for students of the “UML Class Diagrams for Programmers” course and may not be
redistributed.

If you enjoyed this course and you would like to share it with a friend, please use the referral link:
https://www.udemy.com/course/uml-class-diagrams-for-
programmers/?referralCode=617E1ACA20E360B0E995
Course Notes: UML Class Diagrams for Programmers
https://www.udemy.com/course/uml-class-diagrams-for-programmers
©Riaan Nel

• Enums provide attributes (values), but generally do not provide behaviour, so they can
be drawn without the operations section.
• Enums do not need to show attribute types, since all attributes are of the type of the
enum itself.
• Enums also do not need to show access modifiers, since all attributes are implied to be
accessible if the enum itself is accessible.

This is a supplement for students of the “UML Class Diagrams for Programmers” course and may not be
redistributed.

If you enjoyed this course and you would like to share it with a friend, please use the referral link:
https://www.udemy.com/course/uml-class-diagrams-for-
programmers/?referralCode=617E1ACA20E360B0E995

You might also like