Class diagram

source page

Class and Object similarities

Keep in mind that a Class is the blueprint to materialize the idea of something.

Look at Dog and poor Bobby

We have a basic concept of what makes a dog Dog in any sence, Bobby is created (constructed) using the Dog blueprint, and now because it has what a dog should have, we can use Bobby the way we could use any other Dog.

Notation

Class is used to encapsulate state(attributes) and behavior (operaations).

Each operation has a signature, but the class name is the only mandatory info.

Components

Name

• Name of the class which is the first partition's content

Attributes

• The second Partition's content
• Type is shown after the colon
• These ones will be the class variables and property-s in implementation

Operations (Methods)

• The third partition's content
• These are the services the class provides
• When it has signature:
  • The return type is shown after the colon in the end
  • All parameter is listed, with their type colon separated
  • Operations will be the class methods in implementation

Visibility

• + Public
  • Available from anywhere with the right import
• - Private
  • Can only be accessed in the class, not even the derivatives can write it
• ~ Package-Private
  • Inside the package, it is public, but to anyone else, it is considered private
• # Protected
  • Private from the outside, but the derived classes can access it

Parameter Directionality

• in
  • The caller provides this value, but in the method, only a copy is available (not changing the real source)
• out
  • The caller gives reference in order to ensure it will be modified (not by returning)
• inout
  • The caller gives reference, but modification is only a possibility

Perspectives of the class diagram

Class diagram can appear in many scopes, whether it's:

• Conceptual
  • Represends the concept in a domain
• Specification
  • Focus on the interfaces and abstract data types
• Implementation
  • Describes how it will be implemented

Note that Specification scope is not what we learned from GT, that's way too complicated for general use lmao

RelationShips between classes

Note that most part is language specific since some inheritance features are unavailable

e.g. Rust can not use inheritance or most functional languages have only Aggregation and Composition, since they have no classes

The example pictures uses as the origin and as the target of a relationship (just call 'em x and y)

Inheritance

• Represents an "x is a y" relationship
• An abstract class name can be shown in italic
• The sublcasses are specifications (less general) representation for their superclass

Simple Association

Plenty of relation is an assotiation, so in association, I mean the simple assiciation

• A structural link between two peer classes
• There is an association between x and y

This is the most basic, and it can be named after the reap world scenario it represents

Fun fact, x is called <\> class, and y is a <\> class

Cardinality

For ones familiar with Relational Databases and corresponding query languages, these kind of connections are the same with the twist it is among classes, not some kind of abstract storage somewhere else

• One to one
• One to many
• Many to many

Aggregation

• Represents a "x is part of y" relationship
• Many instances (*) of x can be associated with y
• Objects of x and y have separate lifetimes.

x has one or more y (lists for example) but y can live without x (might be stored somewhere else too), not the love story of the year...

Composition

• Special type of aggregation where parts will be destroyed when the whole is destroyed
• Objects of y will live and die with x
  • This way y cannot stand by itseft

Think about it like x has a list of y, and because y only present in x, when x comes to an end, y will follow it into the dark realm of GC purgatory lmao

Dependency

x might use some methods of y, but not stored as a field or attribure

• Special type of association
• If something changes in y, it can cause changes in x, but not the othe way around
• x depends on y

Literally every import we do (and use!) is by definition a dependency. If you download a different version, there might be breaking changes, or it will produce different output (can occur internally too).

Oc. it should not be a problem if the Open-Closed principle isn't forgotten as my dreams are 😿.

Realization

• x is said to realize the blueprint class y
• Every kind of interface implementation is a realization

Full diagram examples

Yes, that is a note, what GT. was using everywhere to pus pseudo-code into the system. Like putting salt into my eyedrops, pathetic.

UML isn't what GT showed, it's much simple, such a beautiful creation to represent a complex problem and explain it like I'm 5

Ty for comming to my TED talk, se ya ✌