diff --git a/monitor/README.md b/monitor/README.md
index ec234cfb6..3041e611b 100644
--- a/monitor/README.md
+++ b/monitor/README.md
@@ -115,10 +115,6 @@ public class Main {
 
 In this example, the `Bank` class is the monitor, and the `transfer` method is the critical section that needs to be executed in a mutually exclusive manner. The `synchronized` keyword in Java is used to implement the Monitor pattern, ensuring that only one thread can execute the `transfer` method at a time.
 
-## Class diagram
-
-![Monitor](./etc/monitor.urm.png "Monitor class diagram")
-
 ## Applicability
 
 The Monitor design pattern should be used in situations where you have shared resources that need to be accessed and manipulated by multiple threads or processes concurrently. This pattern is particularly useful in scenarios where synchronization is necessary to prevent race conditions, data corruption, and inconsistent states. Here are some situations where you should consider using the Monitor pattern:
diff --git a/monostate/README.md b/monostate/README.md
index 31b00827b..2e1d28f07 100644
--- a/monostate/README.md
+++ b/monostate/README.md
@@ -77,10 +77,6 @@ public class App {
 
 In this example, we create two instances of `LoadBalancer`: `loadBalancer1` and `loadBalancer2`. They share the same state. When we make a request via `loadBalancer1`, the request is served by the first server. When we make a request via `loadBalancer2`, the request is served by the second server, not the first one, because the `nextServerIndex` has been updated by `loadBalancer1`. This demonstrates the Monostate pattern in action.
 
-## Class diagram
-
-![Monostate](./etc/monostate.png "MonoState")
-
 ## Applicability
 
 Use the Monostate pattern when