Lab 4

Today we’ll talk about a couple of structural diagrams:

- Class diagram
- Component diagram

~ Reminder ~

Behavioral diagrams:
- are used extensively to describe the functionality of software systems
- show what should happen in a system
- describe how the objects interact with each other to create a functioning system

Structural diagrams:
- state the elements of a system (e.g. classes, objects, packages, modules,
components or interfaces)
- also display the relationships between these elements (classes that inherit from other
classes, objects that contain other objects, which classes belong to which packages,
which nodes are connected etc.)

More info here: https://www.visual-paradigm.com/guide/uml-unified-modeling-

language/behavior-vs-structural-diagram/
https://creately.com/blog/diagrams/uml-diagram-types-examples/
1. Class diagram
- It is the main building block of any object-oriented solution
- It is one of the most useful types of UML diagrams, as they clearly map out the
structure of a particular system by modeling its classes (+ attributes, operations) and
relationships between them

- More info here: https://www.visual-paradigm.com/guide/uml-unified-modeling-

language/what-is-class-diagram/ https://www.visual-paradigm.com/guide/uml-unified-
modeling-language/uml-class-diagram-tutorial/
https://www.lucidchart.com/pages/uml-class-diagram

- Quick reminder: we use classes to create objects

- The standard class in a class diagram is composed of three sections:

- Upper section: Contains the name of the class. This section is always
required
- Middle section: Contains the attributes of the class. Use this section to
describe the qualities of the class
- Bottom section: Includes class operations (methods). Displayed in list format
(each operation takes up its own line). The operations describe how a class
interacts with data and they represent services that the class provides
 - Class visibility (aka Member access modifiers): All classes have different access
levels depending on the access modifier (visibility). These are the most common
access levels with their corresponding symbols:
- Public (+) |
- Private (-) | all applicable to attributes & operations
- Protected (#) |

- Different relationships between classes are shown by different types of arrows:

Association
- default relationship between two classes
- both classes are aware of each other and their
relationship
- structural link between two peer classes

(optional) Cardinality is expressed in terms of:

- one to one
- one to many
- many to many
Inheritance (Generalization)
- means that a child class (subclass) takes on
the functionality of a parent class (superclass):
inherits the attributes & operations of the
superclass in addition to their own
- represents an "is-a" relationship
- the name of the superclass - italics

Realization
- the relationship between the interface and the
implementing class
- the relationship between the blueprint class
and the object containing its respective
implementation level details

Dependency
- a special type of association
- exists between two classes if changes to the
definition of one may cause changes to the
other (but not the other way around)
- Class1 depends on Class2
- an object of one class uses an object of
another class in the code of a method

Aggregation
- a special type of association denoting a
"consists-of" hierarchy
- represents a "part of" relationship
- Class2 is part of Class1

Composition
- a special type of aggregation where parts are
destroyed when the whole is destroyed
- objects of Class2 live and die with Class1
(Class2 cannot stand by itself)
 Example 1: Ordering system

Example 2: Hotel management system

2. Component diagram
- component = a module of classes that represent independent systems or
subsystems with the ability to interface with the rest of the system
- this diagram breaks down the system into various high levels of functionality
- each component is responsible for one clear aim within the entire system and only
interacts with other essential elements on a need-to-know basis

- More info here:

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-
component-diagram/

- Component:

text icon text + icon

- Subsystem:
- has multiple components
- usually independent
- e.g.: db server

- Interfaces:
- provided: symbol
- required: half circle symbol
- Most common relationships:
- Dependency: one component depends on another

- Realization: similar to inheritance

Example 1: VR Rehabilitation system

 Example 2: Ordering system

Example 3: Stock exchange system