0

Diagramas UML e o esforço necessário para aprender programação orientada a objetos

Leonardo Pregnolato
Leonardo Pregnolato

Sou um nativo do século passado. Embora eu considere que eu esteja bem adaptado as tecnologias do presente eu ainda carrego em mim muitas das manias das pessoas que cresceram sem smartphoneswi-fi e tantas telas para tocar e interagir. Um conjunto bem arcaico dessas manias que ainda cultivo diz respeito ao meu modo de aprender: quando o “bicho pega” eu recorro ao papel e aos manuscritos.

Você pode até estar se identificando com isso, afinal, muitas pessoas ainda preferem a boa e velha dupla papel e caneta. Mas eu ainda me pego pensando muito nessa característica de meu aprendizado, pois mesmo quando vou aprender conteúdos relacionados a tecnologia (entenda aqui computação e programação) eu preciso escrever e rabiscar no papel. Seja através de palavras ou desenhos, não importa, muitos conceitos eu só internalizo via escrita à mão.

Estou igual a este cara, preso às tecnologias do passado mesmo diante de um notebook atualizado


Esta mania minha não me incomoda. Pelo contrário, é importante reconhecê-la para que eu possa aprender melhor. No entanto, escrever a mão e anotar no papel pode ser um entrave quando o foco é economizar tempo e organizar todas as anotações que produzimos. Você já tentou encontrar alguma anotação que fez em seu caderninho? E se esse caderninho já estiver totalmente preenchido? Você já perdeu o caderninho?!?!?

Esse texto tem a missão de contar a você como eu fiz para me forçar a fazer as minhas anotações no computador. Isso porque estou me aventurando em aprender programação, então, não dá para fugir dele. Ainda mais, anotar no próprio PC ajuda a tornar as anotações em produto, seja um bloco de código, um programa, uma apresentação ou mesmo um texto.

O que estou estudando? Nada menos do que programação orientada a objetos. Um ramo muito interessante da programação no qual quando você começa a entender como a coisa funciona, a mágica acontece. Parece que você manipula o mundo em poucas linhas de código. É deslumbrante, de verdade, mas confesso que demorei para me achar dentro desse novo mundo.

E é aí que entram as anotações. Chega um momento em meu estudo (e acho que isso deve acontecer com você também) que “nada mais entra na cabeça”. O volume de informação faz com que percamos o controle do entendimento e tudo vira uma bagunça. O que antes parecia simples fica complicado e o que parecia complicado… fica mais complicado ainda! Então eu pego um caderno e começo a escrever, esquematizar, rabiscar, e tudo volta a clarear. Mas, aí começa outra dor de cabeça: o caderno fica cheio de anotações, ele compete espaço na mesa com o laptop, passar anotações para código fica demorado e por aí vai. Deu pra notar que quando eu tento melhorar, eu pioro um pouquinho mais.

Enquanto me martirizo a programação orientada a objetos está lá, impassível, olhando para a minha cara. Ela não debocha, não sente compaixão, apenas se mantém indiferente. Fui eu que decidi conhecê-la e não o contrário. Bem feito para mim.

Foi diante de um desafio de projeto que eu decidi arriscar mais uma vez e a luz se fez presente no fim do túnel. Eu participo de vários bootcamps na plataforma Digital Innovation One (https://digitalinnovation.one/) e em um destes o professor Eliézer Zarpelão (github.com/elizarp) desenvolveu um gerenciador de séries em .NET e em C# e o desafio era que eu conseguisse desenvolver um software parecido.

Esse é o código do projeto (https://github.com/elizarp/dio-dotnet-poo-lab-2) e nele aplicamos vários conceitos de orientação a objetos. Trata-se de um CRUD (Create, Read, Update e Delete), ou em outras palavras um programa simples de cadastro e consulta. Ler o código quando estamos aprendendo uma linguagem de programação é muito importante, mas a falta de experiência com esse modo de encadear as ideias dificulta imaginar o que o programa vai fazer e como vai fazer o que tem que fazer. Então quando eu olhava para o código eu só via uma coisa: o próprio código.


O código sendo código e jogando na minha cara toda a sua indiferença


E estou eu lá tentando entender o código e o que cada parte faz e então me veio uma ideia: e se eu “desenhasse” o programa? Se cada classe fosse um retângulo e dentro deste eu representasse de alguma forma os atributos e métodos, e entre as várias classes eu pudesse descrever a relação entre elas (herança, ou implementação no caso de interfaces). Será que facilitaria? Será que eu veria no código o programa funcionando?

Foi nessa conjectura (e com algumas idas ao Google) que eu acabei descobrindo uma maneira gráfica de representar o programa. E essa maneira já existe há tempos. É o Diagrama UML (Unified Modeling Language) que permite representar as classes em retângulos com três divisões, uma para o nome da classe, outra para os atributos e uma última para os métodos. E o melhor, há vários programas que podemos usar para desenhar esse diagrama. Eu conheci o StarUML e uso sua versão free no meu Ubuntu (https://staruml.io). Pois sou desses que usa Linux.

Para quem quiser saber mais sobre os diagramas UML deixo aqui o link do DevMedia que eu usei para aprender sobre (https://www.devmedia.com.br/orientacoes-basicas-na-elaboracao-de-um-diagrama-de-classes/37224). Conhecer esses diagramas não só me fez dar um upgrade em meus estudos de programação mas também resolveu outra questão que choraminguei muito no início deste texto, ou seja, a dependência do escrever a mão para compreender os conceitos que estudo.

A figura a seguir representa um esquema do diagrama de classe, parte do diagrama UML que representa a classe. Veja que em cada campo está descrito com clareza os seus itens constituintes. Não só há a apresentação do atributo ou parâmetro, como também a sua visibilidade (“+” para itens públicos e “-” para itens privados) e o seu tipo (string, int, double…) e o retorno, para o caso dos métodos (void, int…). Assim, logo de cara, e de uma olhada só, compreendemos a classe como um todo e fica fácil compreender a missão dessa classe dentro do programa.


Esquema simplificado de uma classe em um diagrama UML


E assim no cara a cara com o código e rabiscando ele no StarUML (poderia ser no papel também mas estou me esforçando para me informatizar) que eu consegui, aos trancos e barrancos, representar todo o código que me foi apresentado pelo professor Eliézer em um diagrama UML. Você pode apreciá-lo na figura a seguir. E para não deixar de ressaltar uma das vantagens em fazer este diagrama em um software é que este te obriga a preencher os campos necessários para a confecção do diagrama. Isso significa que, se você esqueceu algum item no seu esquema, está faltando algo também em seu projeto e por consequência faltará também no código.


Diagrama UML (ou quase?) feito por mim para compreender o código e a estrutura do programa supracitado que me foi apresentado em estudo


Mas aí vai um aviso importante: este diagrama pode conter erros! Ainda não estou habituado a toda a linguagem do diagrama UML, que possui um padrão bem definido. E acredito que isso não ocorre por acaso.

Nesse padrão, por exemplo, a seta orientada significa uma relação de herança. A classe Serie herda EntidadeBase. Por que EntidadeBase está em itálico? Está assim porque é uma classe abstrata, ou seja, não pode ter um objeto instanciado referente a essa classe. E por que IRepositório não está representada com um retângulo e sim por um círculo? Porque IRepositorio é uma interface que está sendo implementada na classe SerieRepositorio.

Acredito que esse padrão facilita a vida dos programadores uma vez que desvincula o projeto do software da linguagem a qual ele será escrita. Mesmo porque, em orientação a objetos, uma classe é uma classe quer programamos em java, C#, python ou tantas outras. Mais complicado do que aprender a sintaxe de uma linguagem, que é o que nos assusta em um primeiro momento, é montar na mente todo o esquema do projeto e estabelecer com clareza a relação entre as classes, interfaces, enums e demais objetos de uma aplicação.

Mas você deve estar se perguntando — do mesmo modo que fiquei me perguntando após elaborar o diagrama— onde está a classe main? Pois é, lá está ela no código, lindona e com toda a sua verborragia. Li e reli essa classe e percebi que ela era um tanto “diferentona” das outras. Como representá-la no diagrama?

Foi aí que a ficha caiu: por isso ela é a classe principal, a main!!! É ela que “puxa” as outras classes no momento certo durante a execução do programa e faz a coisa toda acontecer! A classe main é o grande maestro do código e portanto percebi o porquê de ser mais conveniente escrevê-la após todas as classes estarem escritas! Por isso todos os professores fazem assim, agora entendi. Amém!

Esse foi o grande salto no meu aprendizado usando diagramas UML para aprender programação orientada a objetos. Desenhar e escrever (mesmo que no computador) pode continuar fazendo parte de minha rotina de estudos em assuntos digitais. Esquematizar o código me fez ver de modo concreto conceitos abstratos como classe, interface, classe abstrata, herança, atributo método, main

Agora estou igual a este cara, preso aos diagramas UML diante de um notebook atualizado


Qual então será a minha estratégia de agora em diante para estudar programação? Se for para compreender um código já escrito: eu o represento em um diagrama UML. Se for para escrever uma aplicação inédita e desenvolvida por mim: vou criar um diagrama UML para representar todas as classes e demais objetos e ver se todas as funções que pretendo implementar estarão contempladas no código.

Parece trabalhoso toda vez que for ‘codar’ ter que criar um diagrama né? Também acho. Mas também acho que conforme vamos internalizando os conceitos eles se tornam mais automáticos e intuitivos e conseguimos dispensar o uso de algumas ferramentas que nos dão apoio. Se bem que, papel, caneta e agora o StarUML farão parte de minha rotina de maneira mais integrada e sem desconforto. Além do mais, vários sites indicam este tipo de diagrama como uma boa prática de desenvolvimento, até mesmo para apresentar para os clientes, muitas vezes leigos em programação, toda a ideia de uma solução.

Ah! Agora que já sei compreender o código de um modo mais organizado preciso parar de ficar escrevendo aqui e entregar o código que o professor pediu. Com esse diagrama que fiz vou elaborar o da minha própria aplicação. Claro, farei primeiro o seu diagrama e em seguida (tentarei?) vou fazer o seu código. Talvez essa saga renda outro texto, vamos ver.

Quem sabe no futuro só com alguns rabiscos em um papel (acho que esta dupla nunca deixará de nos ajudar) eu não consiga projetar um software inteiro? Não custa acreditar…


Publiquei também no Medium: https://leopregnolato.medium.com/diagramas-uml-e-o-esfor%C3%A7o-necess%C3%A1rio-para-aprender-programa%C3%A7%C3%A3o-orientada-a-objetos-b6858460ddf7

0
0

Comentários (3)

3
Thiago Oliveira

Thiago Oliveira

11/06/2021 18:53

O UML faz parte do start de todo projeto POO, sempre começamos a programar com a matéria mais chata da faculdade (Engenharia de Software hahah), nela que aplicamos esse conceitos.


E parabéns pelo trabalho, ficou bom seu UML

2
Daniel Araújo

Daniel Araújo

11/06/2021 18:51

O bom é que diagramas UML ainda são usados no mercado de trabalho por algumas empresas.

Então seu aprendizado está sendo muito útil, porque com essa prática constante vai entender como funciona a arquitetura de um sistema.

Arquitetos de software tem um salário bem alto. Boa sorte nessa empreitada

1
Cássio Patrizzi

Cássio Patrizzi

11/06/2021 20:10

É isso mesmo Leonardo. Me identifiquei muito com o que você mencionou. Comecei há dois meses na "trilha" tb com o mesmo conceito hahaha. Já usei um brochurão inteiro, mas vem a questão tempo, material, adequação. Gosto de livros, compro sempre em sebos, andei vendo alguns de tecnologia tb mas vi que a opção adequada serão os e-books, os pdf's, páginas na Internet e assim por diante. Afinal, somos da área agora; a realidade é essa, a atualidade. Somos do século passado vivendo em um mundo contemporâneo. Abraço.

Da academia para o mercado

Brasil