\n
![\"Guia](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195e127973c.png\")
<\/p>\n
Parte 1: Os Blocos de Constru\u00e7\u00e3o (Sintaxe e Legenda)<\/h2>\n
Antes de mergulhar no estudo de caso, devemos estabelecer o vocabul\u00e1rio utilizado nos diagramas UML.<\/p>\n
1. Estrutura da Classe e Visibilidade<\/h3>\n
Uma classe \u00e9 representada por um ret\u00e2ngulo dividido em tr\u00eas compartimentos:<\/p>\n
- \n
- \n
Topo:<\/strong> Nome da Classe (por exemplo,
FlightBooking<\/code>).<\/p>\n<\/li>\n- \n
Meio:<\/strong> Propriedades\/Atributos (por exemplo,
+ nameProperty: String<\/code>).<\/p>\n<\/li>\n- \n
Base:<\/strong> M\u00e9todos\/Opera\u00e7\u00f5es (por exemplo,
+ isActive(): boolean<\/code>).<\/p>\n<\/li>\n<\/ul>\nModificadores de Visibilidade:<\/strong><\/p>\n
- \n
- \n
+<\/code>\u00a0P\u00fablico:<\/strong> Acess\u00edvel por qualquer outra classe.<\/p>\n<\/li>\n- \n
-<\/code>\u00a0Privado:<\/strong> Acess\u00edvel apenas dentro da classe.<\/p>\n<\/li>\n- \n
#<\/code>\u00a0Protegido:<\/strong>\u00a0Acess\u00edvel dentro da classe e suas subclasses.<\/p>\n<\/li>\n- \n
~<\/code>\u00a0Pacote:<\/strong>\u00a0Acess\u00edvel apenas dentro do mesmo pacote.<\/p>\n<\/li>\n<\/ul>\n2. Tipos Especiais de Classes<\/h3>\n
- \n
- \n
Interfaces (
<<interface>><\/code>):<\/strong>\u00a0Contratos que definem m\u00e9todos sem implementa\u00e7\u00e3o. Representados por uma caixa verde (neste guia) ou nota\u00e7\u00e3o padr\u00e3o.<\/p>\n- \n
- \n
Exemplo:<\/em>\u00a0
UserRepo<\/code>\u00a0com\u00a0+ method(): void<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Classes Abstratas (
<<abstract>><\/code>):<\/strong>\u00a0Classes base que n\u00e3o podem ser instanciadas diretamente. Podem conter m\u00e9todos abstratos.<\/p>\n- \n
- \n
Exemplo:<\/em>\u00a0
Componente<\/code>\u00a0com\u00a0+ render(): void \/\/ abstract<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Enumera\u00e7\u00f5es:<\/strong>\u00a0Um conjunto de constantes nomeadas.<\/p>\n
- \n
- \n
Exemplo:<\/em>\u00a0
JobStatus<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nExemplo de Diagrama de Classes do Sistema de Pedidos<\/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 INTERFACES \u2014
\ninterface PaymentGateway {
\n+ process(amount: double): boolean
\n}<\/p>\n\u2018 \u2014 CLASSES ABSTRATOS \u2014
\nabstract class Order {
\n# orderId: String
\n# totalAmount: double
\n+ {abstract} calculateTax(): double
\n+ getSummary(): String
\n}<\/p>\n\u2018 \u2014 CLASSES \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 RELACIONAMENTOS \u2014’
\nOrder <|\u2013 PhysicalOrder
\nOrder <|\u2013 DigitalOrder<\/p>\nOrder *\u2013 \u201c1..*\u201d OrderItem : cont\u00e9m
\nOrder ..> PaymentGateway : utiliza<\/p>\nPaymentGateway <|.. PayPalGateway<\/p>\n
@enduml<\/p>\n
\nParte 2: Relacionamentos e Multiplicidade<\/h2>\n
As linhas que conectam as classes definem como elas interagem.<\/p>\n
1. Tipos de Associa\u00e7\u00e3o<\/h3>\n
- \n
- \n
Heran\u00e7a (Generaliza\u00e7\u00e3o):<\/strong>Linha s\u00f3lida com um tri\u00e2ngulo vazio. Rela\u00e7\u00e3o \u201c\u00e9-um\u201d.<\/p>\n
- \n
- \n
Exemplo:<\/em>\u00a0
Carro<\/code>\u00a0e\u00a0Motocicleta<\/code>\u00a0herdam de\u00a0Ve\u00edculo<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Implementa\u00e7\u00e3o:<\/strong>Linha tracejada com um tri\u00e2ngulo vazio. Uma classe cumpre um contrato de interface.<\/p>\n
- \n
- \n
Exemplo:<\/em>\u00a0
Carro<\/code>\u00a0implementa\u00a0Dirig\u00edvel<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Composi\u00e7\u00e3o (Propriedade Forte):<\/strong>Linha s\u00f3lida com um\u00a0losango preenchido<\/strong>. A \u201cparte\u201d n\u00e3o pode existir sem o \u201ctodo.\u201d<\/p>\n
- \n
- \n
Exemplo:<\/em>\u00a0
Restaurante<\/code> (Todo) possuiCard\u00e1pio<\/code> (Parte). Se o restaurante fechar, o card\u00e1pio deixar\u00e1 de existir.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Agrega\u00e7\u00e3o:<\/strong> Linha s\u00f3lida com um losango vazio<\/strong>. Uma rela\u00e7\u00e3o \u201ctem-um\u201d onde as partes podem existir independentemente.<\/p>\n
- \n
- \n
Exemplo:<\/em>\u00a0
Pedido<\/code> agregandoRestaurante<\/code> (O restaurante existe mesmo se o pedido for exclu\u00eddo).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n2. Legenda de Multiplicidade<\/h3>\n
Os n\u00fameros nas extremidades das linhas indicam a cardinalidade:<\/p>\n
- \n
- \n
1<\/code>: Exatamente um.<\/p>\n<\/li>\n- \n
0..1<\/code>: Zero ou um (Opcional).<\/p>\n<\/li>\n- \n
1..*<\/code>: Um ou mais (Lista obrigat\u00f3ria).<\/p>\n<\/li>\n- \n
*<\/code>: Muitos (Zero ou mais).<\/p>\n<\/li>\n<\/ul>\nOs conceitos de heran\u00e7a, implementa\u00e7\u00e3o, composi\u00e7\u00e3o e agrega\u00e7\u00e3o Exemplo<\/h3>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a19600180d6b.png\")
<\/p>\n\n@startuml<\/div>\n\u2018 Interfaces e Classes Base<\/div>\ninterface Dirig\u00edvel {<\/div>\n+ dirigir()<\/div>\n}<\/div>\nclasse abstrata Vehicle {<\/div>\n+ startEngine()<\/div>\n}<\/div>\n\u2018 Classes<\/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 Relacionamentos<\/div>\n\u2018 1. Heran\u00e7a (Generaliza\u00e7\u00e3o)<\/div>\nVehicle <|\u2013 Car<\/div>\nVehicle <|\u2013 Motorcycle<\/div>\n\u2018 2. Implementa\u00e7\u00e3o<\/div>\nDrivable <|.. Car<\/div>\n\u2018 3. Composi\u00e7\u00e3o (Propriedade Forte)<\/div>\nRestaurant *\u2013 Menu : possui<\/div>\n\u2018 4. Agrega\u00e7\u00e3o<\/div>\nOrder o\u2013 Restaurant : envolve<\/div>\n\u2018 Exemplos de Multiplicidade<\/div>\n\u2018 Restaurant possui um ou muitos Menus (1..*)<\/div>\n\u2018 Order envolve zero ou um Restaurant (0..1)<\/div>\nRestaurant \u201c1\u201d *\u2013 \u201c1..*\u201d Menu<\/div>\nPedido “1” o\u2013 “0..1” Restaurante<\/div>\n@enduml<\/div>\n<\/div>\n
\nParte 3: Estudo de Caso do Mundo Real: Plataforma Unificada de Entrega de Alimentos<\/h2>\n
Esta se\u00e7\u00e3o analisa o diagrama central da folha de resumo, decompondo a arquitetura de um aplicativo de entrega de alimentos.<\/p>\n
1. A Hierarquia de Usu\u00e1rios (Heran\u00e7a e Composi\u00e7\u00e3o)<\/h3>\n
O sistema come\u00e7a com uma classe gen\u00e9rica Usu\u00e1rio<\/strong> classe, marcada como Abstrata<\/strong>. Isso garante que nenhum objeto gen\u00e9rico “Usu\u00e1rio” seja criado, apenas tipos espec\u00edficos.<\/p>\n
- \n
- \n
Heran\u00e7a:<\/strong>\u00a0
Cliente<\/code> eEntregador<\/code> estendemUsu\u00e1rio<\/code>.<\/p>\n<\/li>\n- \n
Composi\u00e7\u00e3o:<\/strong><\/p>\n
- \n
- \n
Cliente<\/code> possui umEndere\u00e7o de Entrega<\/code> (Propriedade Forte).<\/p>\n<\/li>\n- \n
Entregador<\/code> possuiDetalhes do Ve\u00edculo<\/code> (Propriedade Forte).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n2. O Ecossistema de Restaurante e Card\u00e1pio<\/h3>\n
Esta se\u00e7\u00e3o demonstra aninhamento profundo e cole\u00e7\u00f5es.<\/p>\n
- \n
- \n
Implementa\u00e7\u00e3o de Interface:<\/strong>\u00a0
Restaurante<\/code> implementa<<interface>> Localiz\u00e1vel<\/code>, garantindo que cada restaurante tenha dados de localiza\u00e7\u00e3o.<\/p>\n<\/li>\n- \n
Cadeia de Composi\u00e7\u00e3o:<\/strong><\/p>\n
- \n
- \n
Restaurante<\/code> (1) possui fortementeCard\u00e1pio<\/code>\u00a0(1).<\/p>\n<\/li>\n- \n
Card\u00e1pio<\/code> cont\u00e9mCategoria de Card\u00e1pio<\/code>\u00a0(1..*).<\/p>\n<\/li>\n- \n
Categoria de Card\u00e1pio<\/code> cont\u00e9mItem de Card\u00e1pio<\/code>\u00a0(*).<\/p>\n<\/li>\n- \n
Nota:<\/em> Esta estrutura imp\u00f5e que um Item de Card\u00e1pio n\u00e3o pode existir sem uma Categoria, que n\u00e3o pode existir sem um Card\u00e1pio.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
3. Processamento de Pedidos e Pagamentos<\/h3>\n
- \n
- \n
Estrutura do Pedido:<\/strong><\/p>\n
- \n
- \n
Pedido<\/code> tem um relacionamento comRestaurante<\/code> (Agrega\u00e7\u00e3o).<\/p>\n<\/li>\n- \n
Pedido<\/code> possui fortementeItem de Linha do Pedido<\/code>\u00a0(1..*).<\/p>\n<\/li>\n- \n
Pedido<\/code> tem umPagamento<\/code> (0..1), indicando que o pagamento \u00e9 opcional durante a fase inicial de cria\u00e7\u00e3o.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Estrat\u00e9gia de Pagamento (Polimorfismo):<\/strong><\/p>\n
- \n
- \n
O sistema utiliza uma interface
<<interface>> ProcessadorDePagamento<\/code>.<\/p>\n<\/li>\n- \n
Classes concretas
StripeProcessor<\/code> ePayPalProcessor<\/code> implementam esta interface. Isso permite que o sistema altere as gateways de pagamento sem modificar o n\u00facleoPedido<\/code> l\u00f3gica.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n4. Classe Abstrata vs. Interface (Exemplo do Ve\u00edculo)<\/h3>\n
O canto superior direito da folha de resumo esclarece uma confus\u00e3o comum:<\/p>\n
- \n
- \n
Classe Abstrata (
Ve\u00edculo<\/code>):<\/strong>\u00a0Carro<\/code> eMoto<\/code> herdam deVe\u00edculo<\/code>. Isso implica que eles compartilham dados\/estrutura essenciais (por exemplo,tipoDeMotor<\/code>,\u00a0rodas<\/code>).<\/p>\n<\/li>\n- \n
Interface (
Dirig\u00edvel<\/code>):<\/strong>\u00a0Carro<\/code> implementaDirig\u00edvel<\/code>. Isso implicaCarro<\/code> tem comportamento espec\u00edfico (drive()<\/code>) queMoto<\/code> pode n\u00e3o ter (ou pode implementar de forma diferente).<\/p>\n<\/li>\n<\/ul>\n
\nParte 4: Visualizando com PlantUML<\/h2>\n
Abaixo est\u00e1 o c\u00f3digo PlantUML para gerar a estrutura central da “Plataforma Unificada de Entrega de Alimentos” descrita no estudo de caso. Voc\u00ea pode copiar isso para qualquer editor PlantUML para visualizar o diagrama.<\/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