\n
![\"Podr\u0119czny](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195e127973c.png\")
<\/p>\n
Cz\u0119\u015b\u0107 1: Elementy podstawowe (sk\u0142adnia i legenda)<\/h2>\n
Zanim przejdziemy do studium przypadku, musimy ustali\u0107 s\u0142ownictwo u\u017cywane w diagramach UML.<\/p>\n
1. Struktura klasy i widoczno\u015b\u0107<\/h3>\n
Klasa jest reprezentowana przez prostok\u0105t podzielony na trzy sekcje:<\/p>\n
- \n
- \n
G\u00f3rna:<\/strong> Nazwa klasy (np.
RezerwacjaLotu<\/code>).<\/p>\n<\/li>\n- \n
\u015arodkowa:<\/strong> W\u0142a\u015bciwo\u015bci\/Atrybuty (np.
+ nazwaWlasnosci: String<\/code>).<\/p>\n<\/li>\n- \n
Dolna:<\/strong> Metody\/Operacje (np.
+ jestAktywny(): boolean<\/code>).<\/p>\n<\/li>\n<\/ul>\nModyfikatory widoczno\u015bci:<\/strong><\/p>\n
- \n
- \n
+<\/code>\u00a0Publiczne:<\/strong> Dost\u0119pne dla dowolnej innej klasy.<\/p>\n<\/li>\n- \n
-<\/code>\u00a0Prywatne:<\/strong> Dost\u0119pne wy\u0142\u0105cznie wewn\u0105trz klasy.<\/p>\n<\/li>\n- \n
#<\/code>\u00a0Chroniony:<\/strong>\u00a0Dost\u0119pny wewn\u0105trz klasy i jej klas pochodnych.<\/p>\n<\/li>\n- \n
~<\/code>\u00a0Pakiet:<\/strong>\u00a0Dost\u0119pny tylko wewn\u0105trz tego samego pakietu.<\/p>\n<\/li>\n<\/ul>\n2. Specjalne typy klas<\/h3>\n
- \n
- \n
Interfejsy (
<<interfejs>><\/code>):<\/strong>\u00a0Umowy definiuj\u0105ce metody bez implementacji. Reprezentowane zielonym polem (w tym podpowiedzi) lub standardow\u0105 notacj\u0105.<\/p>\n- \n
- \n
Przyk\u0142ad:<\/em>\u00a0
UserRepo<\/code>\u00a0z\u00a0+ metoda(): void<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Klasy abstrakcyjne (
<<abstrakcyjna>><\/code>):<\/strong>\u00a0Klasy bazowe, kt\u00f3rych nie mo\u017cna zainstantowa\u0107 bezpo\u015brednio. Mog\u0105 zawiera\u0107 metody abstrakcyjne.<\/p>\n- \n
- \n
Przyk\u0142ad:<\/em>\u00a0
Component<\/code>\u00a0z\u00a0+ render(): void \/\/ abstrakcyjna<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Wyliczenia:<\/strong>\u00a0Zbi\u00f3r nazwanych sta\u0142ych.<\/p>\n
- \n
- \n
Przyk\u0142ad:<\/em>\u00a0
JobStatus<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nPrzyk\u0142ad diagramu klas systemu zam\u00f3wie\u0144<\/h2>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195f79a1fa7.png\")
<\/p>\n\u00a0<\/p>\n
@startuml
\nskinparam classAttributeIconSize 0
\nskinparam shadowing false<\/p>\n\u2018 \u2014 INTERFEJSY \u2014
\ninterface PaymentGateway {
\n+ process(amount: double): boolean
\n}<\/p>\n\u2018 \u2014 KLASY ABSTRAKCYJNE \u2014
\nabstract class Order {
\n# orderId: String
\n# totalAmount: double
\n+ {abstract} calculateTax(): double
\n+ getSummary(): String
\n}<\/p>\n\u2018 \u2014 KLASY \u2014
\nclass PhysicalOrder {
\n\u2013 shippingWeight: double
\n+ calculateTax(): double
\n}<\/p>\nclass DigitalOrder {
\n\u2013 downloadLink: String
\n+ calculateTax(): double
\n}<\/p>\nclass OrderItem {
\n\u2013 productName: String
\n\u2013 price: double
\n\u2013 quantity: int
\n}<\/p>\nclass PayPalGateway {
\n+ process(amount: double): boolean
\n}<\/p>\n\u2018 \u2014 RELACJE \u2014’
\nOrder <|\u2013 PhysicalOrder
\nOrder <|\u2013 DigitalOrder<\/p>\nOrder *\u2013 \u201c1..*\u201d OrderItem : zawiera
\nOrder ..> PaymentGateway : u\u017cywa<\/p>\nPaymentGateway <|.. PayPalGateway<\/p>\n
@enduml<\/p>\n
\nCz\u0119\u015b\u0107 2: Relacje i Mno\u017cno\u015b\u0107<\/h2>\n
Linie \u0142\u0105cz\u0105ce klasy okre\u015blaj\u0105 spos\u00f3b ich interakcji.<\/p>\n
1. Typy asocjacji<\/h3>\n
- \n
- \n
Dziedziczenie (Uog\u00f3lnienie):<\/strong>\u00a0Ci\u0105g\u0142a linia z pustym tr\u00f3jk\u0105tem. Relacja \u201ejest-a\u201d.<\/p>\n
- \n
- \n
Przyk\u0142ad:<\/em>\u00a0
Samoch\u00f3d<\/code>\u00a0i\u00a0Motocykl<\/code>\u00a0dziedzicz\u0105 z\u00a0Pojazd<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Implementacja:<\/strong>\u00a0Przerywana linia z pustym tr\u00f3jk\u0105tem. Klasa realizuje kontrakt interfejsu.<\/p>\n
- \n
- \n
Przyk\u0142ad:<\/em>\u00a0
Samoch\u00f3d<\/code>\u00a0implementuje\u00a0Jedny<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Kompozycja (Silne w\u0142asno\u015b\u0107):<\/strong>\u00a0Ci\u0105g\u0142a linia z\u00a0wype\u0142nionym rombem<\/strong>. \u201eCz\u0119\u015b\u0107\u201d nie mo\u017ce istnie\u0107 bez \u201eca\u0142o\u015bci.\u201d<\/p>\n
- \n
- \n
Przyk\u0142ad:<\/em>\u00a0
Restauracja<\/code> (Ca\u0142o\u015b\u0107) posiadaMenu<\/code> (Cz\u0119\u015b\u0107). Je\u015bli restauracja zamknie si\u0119, menu zniknie.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Agregacja:<\/strong> Linia ci\u0105g\u0142a z pustym rombem<\/strong>. Relacja \u201ema-a\u201d, w kt\u00f3rej cz\u0119\u015bci mog\u0105 istnie\u0107 niezale\u017cnie.<\/p>\n
- \n
- \n
Przyk\u0142ad:<\/em>\u00a0
Zam\u00f3wienie<\/code> agreguj\u0105ceRestauracja<\/code> (Restauracja istnieje nawet je\u015bli zam\u00f3wienie zostanie usuni\u0119te).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n2. Legenda mnogo\u015bci<\/h3>\n
Liczby na ko\u0144cach linii wskazuj\u0105 kardynalno\u015b\u0107:<\/p>\n
- \n
- \n
1<\/code>: Dok\u0142adnie jeden.<\/p>\n<\/li>\n- \n
0..1<\/code>: Zero lub jeden (Opcjonalne).<\/p>\n<\/li>\n- \n
1..*<\/code>: Jeden lub wi\u0119cej (Obowi\u0105zkowa lista).<\/p>\n<\/li>\n- \n
*<\/code>: Wiele (Zero lub wi\u0119cej).<\/p>\n<\/li>\n<\/ul>\nPrzyk\u0142ad koncepcji dziedziczenia, implementacji, kompozycji i agregacji<\/h3>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a19600180d6b.png\")
<\/p>\n\n@startuml<\/div>\n\u201eInterfejsy i klasy bazowe<\/div>\ninterface Drivable {<\/div>\n+ drive()<\/div>\n}<\/div>\nabstraktna klasa Vehicle {<\/div>\n+ startEngine()<\/div>\n}<\/div>\n\u2018 Klasy<\/div>\nclass Car {<\/div>\n}<\/div>\nclass Motorcycle {<\/div>\n}<\/div>\nclass Restaurant {<\/div>\n\u2013 name: String<\/div>\n}<\/div>\nclass Menu {<\/div>\n}<\/div>\nclass Order {<\/div>\n}<\/div>\n\u2018 Relacje<\/div>\n\u2018 1. Dziedziczenie (Uog\u00f3lnienie)<\/div>\nVehicle <|\u2013 Car<\/div>\nVehicle <|\u2013 Motorcycle<\/div>\n\u2018 2. Implementacja<\/div>\nDrivable <|.. Car<\/div>\n\u2018 3. Kompozycja (Silne w\u0142asno\u015b\u0107)<\/div>\nRestaurant *\u2013 Menu : posiada<\/div>\n\u2018 4. Agregacja<\/div>\nOrder o\u2013 Restaurant : obejmuje<\/div>\n\u2018 Przyk\u0142ady mnogo\u015bci<\/div>\n\u2018 Restauracja ma jeden lub wiele Menu (1..*)<\/div>\n\u2018 Zam\u00f3wienie obejmuje zero lub jedn\u0105 Restauracj\u0119 (0..1)<\/div>\nRestaurant \u201c1\u201d *\u2013 \u201c1..*\u201d Menu<\/div>\nZam\u00f3wienie “1” o\u2013 “0..1” Restauracja<\/div>\n@enduml<\/div>\n<\/div>\n
\nCz\u0119\u015b\u0107 3: Przypadek z praktyki: Zintegrowana platforma dostaw \u017cywno\u015bci<\/h2>\n
Ten rozdzia\u0142 analizuje centralny diagram z notatki, rozk\u0142adaj\u0105c architektur\u0119 aplikacji do dostaw \u017cywno\u015bci.<\/p>\n
1. Hierarchia u\u017cytkownik\u00f3w (dziedziczenie i kompozycja)<\/h3>\n
System rozpoczyna si\u0119 od og\u00f3lnego U\u017cytkownik<\/strong> klasy oznaczonej jako Abstrakcyjna<\/strong>. Zapewnia to, \u017ce nie tworzy si\u0119 obiekt\u00f3w og\u00f3lnego typu “U\u017cytkownik”, a jedynie konkretne typy.<\/p>\n
- \n
- \n
Dziedziczenie:<\/strong>\u00a0
Klient<\/code> orazKierowca<\/code> rozszerzaj\u0105U\u017cytkownik<\/code>.<\/p>\n<\/li>\n- \n
Kompozycja:<\/strong><\/p>\n
- \n
- \n
Klient<\/code> posiadaAdres dostawy<\/code> (Silne w\u0142asno\u015bci).<\/p>\n<\/li>\n- \n
Kierowca<\/code> posiadaDane pojazdu<\/code> (Silne w\u0142asno\u015bci).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n2. Ekosystem restauracji i menu<\/h3>\n
Ten rozdzia\u0142 przedstawia g\u0142\u0119bokie zagnie\u017cd\u017cenie i kolekcje.<\/p>\n
- \n
- \n
Implementacja interfejsu:<\/strong>\u00a0
Restauracja<\/code> implementuje<<interfejs>> Lokalizowalny<\/code>, zapewniaj\u0105c, \u017ce ka\u017cda restauracja posiada dane lokalizacyjne.<\/p>\n<\/li>\n- \n
\u0141a\u0144cuch kompozycji:<\/strong><\/p>\n
- \n
- \n
Restauracja<\/code> (1) silnie posiadaMenu<\/code>\u00a0(1).<\/p>\n<\/li>\n- \n
Menu<\/code> zawieraKategoria menu<\/code>\u00a0(1..*).<\/p>\n<\/li>\n- \n
Kategoria menu<\/code> zawieraPozycja menu<\/code>\u00a0(*).<\/p>\n<\/li>\n- \n
Uwaga:<\/em> Ta struktura wymusza, \u017ce pozycja menu nie mo\u017ce istnie\u0107 bez kategorii, kt\u00f3ra nie mo\u017ce istnie\u0107 bez menu.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
3. Przetwarzanie zam\u00f3wie\u0144 i p\u0142atno\u015bci<\/h3>\n
- \n
- \n
Struktura zam\u00f3wienia:<\/strong><\/p>\n
- \n
- \n
Zam\u00f3wienie<\/code> ma relacj\u0119 zRestauracja<\/code> (agregacja).<\/p>\n<\/li>\n- \n
Zam\u00f3wienie<\/code> silnie posiadaPozycja zam\u00f3wienia<\/code>\u00a0(1..*).<\/p>\n<\/li>\n- \n
Zam\u00f3wienie<\/code> maP\u0142atno\u015b\u0107<\/code> (0..1), co oznacza, \u017ce p\u0142atno\u015b\u0107 jest opcjonalna w fazie pocz\u0105tkowej tworzenia.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Strategia p\u0142atno\u015bci (polimorfizm):<\/strong><\/p>\n
- \n
- \n
System wykorzystuje interfejs
<<interface>> PaymentProcessor<\/code>.<\/p>\n<\/li>\n- \n
Klasy konkretne
StripeProcessor<\/code> orazPayPalProcessor<\/code> implementuj\u0105 ten interfejs. Pozwala to systemowi prze\u0142\u0105cza\u0107 bramki p\u0142atno\u015bci bez zmiany rdzeniowejZam\u00f3wienie<\/code> logiki.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n4. Klasa abstrakcyjna vs. interfejs (przyk\u0142ad z pojazdami)<\/h3>\n
W prawym g\u00f3rnym rogu podpowiedzi wyja\u015bniono powszechne nieporozumienie:<\/p>\n
- \n
- \n
Klasa abstrakcyjna (
Pojazd<\/code>):<\/strong>\u00a0Samoch\u00f3d<\/code> orazMotocykl<\/code> dziedzicz\u0105 zPojazd<\/code>. Oznacza to, \u017ce dziel\u0105 si\u0119 rdzeniowymi danymi\/struktur\u0105 (np.typSilnika<\/code>,\u00a0ko\u0142a<\/code>).<\/p>\n<\/li>\n- \n
Interfejs (
Jedny<\/code>):<\/strong>\u00a0samochodem<\/code> implementujeinterfejs Przejazdny<\/code>. Oznacza to, \u017cesamochodem<\/code> ma specyficzne zachowanie (drive()<\/code>) kt\u00f3reMotocykl<\/code> mo\u017ce nie posiada\u0107 (lub mo\u017ce by\u0107 zaimplementowane inaczej).<\/p>\n<\/li>\n<\/ul>\n
\nCz\u0119\u015b\u0107 4: Wizualizacja z u\u017cyciem PlantUML<\/h2>\n
Poni\u017cej znajduje si\u0119 kod PlantUML do wygenerowania podstawowej struktury “Zintegrowanej Platformy Dostaw \u017bywno\u015bci” opisanej w studium przypadku. Mo\u017cesz skopiowa\u0107 go do dowolnego edytora PlantUML, aby zobaczy\u0107 diagram.<\/p>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195d5d056af.png\")
<\/p>\n\n\nPlantUML<\/span> - \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n