O objetivo desta lição é apresentar a você a Linguagem de Modelagem Unificada (UML – Unified Modeling Language), as suas características, a aplicabilidade e as formas para se projetar softwares, por meio dos diagramas da UML. A UML é a linguagem padrão do mercado para se projetar sistemas computacionais. É amplamente utilizada por organizações de todo o mundo quando se busca ter um projeto detalhado de um software.

Até meados dos anos 1990, predominava entre os desenvolvedores de software o uso de Diagramas de Fluxo de Dados, Diagrama de Contexto e Diagrama Entidade-Relacionamento para criar projetos de software.  Após o surgimento do paradigma de orientação a objetos, que alterou a forma como os programas de computador eram criados, viu-se a necessidade de alterar a forma como os softwares eram projetados.

A UML foi criada em meados da década de 1990, por Grady Booch, Ivar Jacobson e James Rumbaugh. Cada um destes autores possuía métodos particulares (Booch, OOSE e OMT, respectivamente) para criar projetos de software que seguiam os princípios da orientação a objetos. Quando estes pesquisadores perceberam que seus métodos estavam convergindo na mesma direção, mas de maneira independente, resolveram criar uma linguagem única de modelagem de software. O objetivo era que essa linguagem unificada pudesse abranger todas as características principais dos métodos de cada um deles.

Assim, a UML logo se tornou um padrão no mercado para modelar e projetar software. Softwares-house (empresas que desenvolvem software para vender) e organizações de diferentes ramos de todo o mundo utilizam a linguagem UML para criar os seus projetos de software.

Vamos refletir sobre a aplicabilidade da linguagem de modelagem (UML). Imagine que você  desenvolverá o projeto de um software. Você já passou pela etapa de engenharia de requisitos, já sabe quais são os requisitos funcionais e não funcionais, mas precisa criar o projeto de todo o software para que um ou mais programadores possam ler o seu projeto e codifiquem o que você projetou.

A UML pode fornecer a um tecnólogo em análise e projeto de sistemas ferramentas semelhantes àquelas que um engenheiro civil ou arquiteto utiliza para projetar uma casa ou um prédio. Nós sabemos que não é uma boa ideia tentar construir uma casa ou um prédio sem que você possua o projeto estrutural, o projeto arquitetônico, o projeto elétrico, o projeto hidráulico, entre outros associados a uma construção com certo nível de tamanho e complexidade. Esta ideia é válida também para o desenvolvimento de software. Não é uma boa ideia você começar a construir o seu software sem ter um projeto do que você quer construir.

Muitos alunos me perguntam: É possível construir um software sem fazer o projeto? A minha resposta é sim e não.  Na verdade, dependerá do tipo de software, do tamanho dele e do método de desenvolvimento de software que se está seguindo. A UML tende a ser mais aplicada em métodos prescritivos, mas pode ser usada em menor proporção para auxiliar em métodos ágeis.

O fundamental é que o profissional conheça as ferramentas existentes e as use em favor próprio. Não há regras rígidas que impeçam que você use um ou outro recurso. O bom senso, a experiência, o conhecimento dos métodos, as ferramentas e os processos de desenvolvimento de software é que guiarão o tecnólogo em análise e projeto de sistemas no melhor caminho, e este é o nosso objetivo aqui na disciplina. 

De acordo com Rumbaugh et al. (2000, p. 32) a UML pode ser definida como:

A UML é voltada para o desenvolvimento de sistemas orientados a objetos e NÃO é um método, a UML é uma linguagem de modelagem e define uma notação e uma estrutura gráfica para que os projetos sejam desenvolvidos. A notação representa a sintaxe da linguagem composta por elementos gráficos (Diagramas). Para que seja possível criar um projeto utilizando a UML, nós precisaremos de duas coisas: a primeira é um software que suporte a modelagem por UML, neste sentido, sugiro que você use o software Visual Paradigm na sua versão Community (https://www.visual-paradigm.com/download/community.jsp ). Esse software permite criar projetos profissionais usando a UML. O segundo elemento que precisamos conhecer são os diagramas da UML, por meio deles conseguiremos criar o projeto do software. Então vamos lá!

Diagramas da UML

O diagrama é uma representação gráfica de um conjunto de elementos. A UML 2 é composta por 14 diagramas divididos em dois grupos: diagramas estruturais e diagramas comportamentais, conforme Figura 1.

A Figura 1 permite ter uma noção geral dos diagramas que compõem a UML e sua divisão nos dois grupos. O grupo de diagramas estruturais possui como objetivo permitir a modelagem da estrutura estática do software. O principal diagrama desse grupo é o Diagrama de Classe, que permite que seja modelada a estrutura de armazenamento de dados do sistema, como a definição das classes e seus atributos (discutiremos em detalhes esse diagrama em uma lição específica devido à sua complexidade).

O grupo de diagramas comportamentais permite a modelagem dinâmica do sistema, como de que maneira os dados trafegarão por meio dos processos, qual usuário usará qual requisito funcional. Trata-se de um grupo de diagramas que modela a funcionalidade processual interna dos requisitos funcionais do software. O principal diagrama desse grupo é o Diagrama de Caso de Uso (discutiremos em detalhes esse diagrama em uma lição específica devido à sua complexidade).

 A seguir serão apresentados os dois principais diagramas da UML 2: Diagrama de Casos de Uso e o Diagrama de Classe.

Diagrama de Casos de Uso

Este é o diagrama mais geral e informal da UML, sendo utilizado principalmente para auxiliar no levantamento e na análise dos requisitos. O Diagrama de Casos de Uso deve apresentar uma linguagem simples e de fácil compreensão para que os usuários possam ter uma ideia geral de como o sistema funcionará (GUEDES, 2011). Vamos analisar a estrutura de um Diagrama de Caso de Uso na Figura 2.

O diagrama de caso de uso apresentado na Figura 2 apresenta alguns elementos gráficos que devemos conhecer para analisar e criar esse tipo de diagrama. O primeiro elemento é o Caso de Uso. O Caso de Uso em um diagrama desse modelo é representado por uma elipse com um texto dentro que SEMPRE deverá usar um verbo no infinitivo (aqueles verbos que terminam com AR, ER e IR) e um ou dois substantivos.

Exemplos de Casos de Uso podem ser: Emitir Extrato, Emitir Saldo, Encerrar Conta, Registrar Movimento, Realizar Saque, Manter Cliente, Abrir Conta Comum ou Realizar Depósito. Perceba que todos os nomes estão com um verbo que terminam em AR, ER ou IR e, após esse verbo, tem um ou dois substantivos (um nome que corresponde àquela funcionalidade).

Os Atores são outro tipo de elemento obrigatório em um diagrama de Caso de Uso. Atores são representados pelos bonecos que estão nas laterais do diagrama. Exemplos de atores podem ser: Funcionário, Cliente ou Sistema de Vendas.

 Diagrama de Classe

O Diagrama de Classe da UML permite a modelagem da estrutura de armazenamento dos dados que comporão o sistema. Nós usamos os termos Classe para representar uma estrutura mais ampla, e atributo para representar os dados que compõem aquela classe. A seguir, na Figura 3, é apresentada a estrutura de uma classe.

O nome da classe é “Produtos”, e ela possui cinco atributos: idProduto do tipo inteiro, nomeProduto do tipo string (texto), preçoProduto do tipo real (número com casas decimais), dataValidadeProduto do tipo Date (tipo de Data) e qtdeEmEstoque do tipo inteiro (valor numérico sem casas decimais).

A última parte de uma Classe são os seus Métodos, no caso da Figura 3 há dois métodos: o método atualizar_estoque e informar_vencimento. Métodos são as ações que uma classe pode realizar, tudo aquilo que uma classe faz em termos de funcionalidades. Os métodos SEMPRE possuirão uma codificação, ou seja, a parte da Classe que possui código associado à linguagem de programação que está sendo usada no software estará no método de cada classe. Uma mesma classe pode zero ou muitos métodos.

O Diagrama de Classe também tem um elemento gráfico que representa a interface que o usuário do software enxerga – é como se fosse a página inicial de uma página Web. Veja a Figura 4:

O segundo elemento gráfico representa o controlador ou, também, o elemento responsável por “disparar” os eventos que estão dentro das classes. Por exemplo, quando alguém clica no botão da interface apresentada, este ato de clicar no botão ativa o Controlador que executa o evento correspondente na classe. 

Na sequência, é apresentado parte de um Diagrama de Classe que envolve os três elementos discutidos anteriormente (interface, controlador dos métodos e a classe).

A UML é uma linguagem de modelagem de sistemas computacionais bastante ampla, e o nosso objetivo aqui foi apenas apresentar para você os seus principais diagramas e uma breve explicação de cada um. Apesar de existirem muitos diagramas, considero que os principais diagramas e que um profissional Analista de Projeto de Sistemas deve ter um domínio aprofundado são os diagramas de Caso de Uso e de Classe. Esses são, sem dúvida, os diagramas principais da UML e, se bem executados, viabilizarão ótimos diagramas na sequência.

Pensando nisso, sugiro que você tente desenhar o diagrama de caso de uso de um sistema para a venda de ingressos de sessões de cinema. Talvez você já tenha visto ou ouvido falar daqueles totens (ex.: parecem caixas eletrônicos de banco) em que você pode comprar o ingresso para uma sessão de cinema em um shopping sem a ajuda do funcionário do cinema. Vamos tentar identificar os Casos de Uso e as possíveis classes que um sistema desse tipo possa ter. Para identificarmos os Casos de Uso, imagine as funcionalidades (requisitos funcionais) que esse tipo de sistema possui. Primeiro, você precisa escolher a sessão a que deseja assistir, logo, existirá um caso de uso chamado “Escolher_sessão”. Após escolhida a sessão, você poderá adicionar à compra da sua sessão algumas opções de alimentos ou bebidas (ex.: pipoca e suco). Neste momento, teríamos outra funcionalidade que seria um “extend” do Caso de Uso “Escolher_sessão” que podemos chamar de “Inserir_opcionais”. Por fim, você deve efetuar o pagamento da sessão e dos opcionais que escolheu ou não. Para isso teremos o Caso de Uso “Efetuar_Pagamento”. O pagamento só poderá ser feito em cartão de crédito ou débito, logo, teremos um “include” – uma obrigatoriedade do caso de uso “Escolher_Forma_Pagamento”. Após a forma de pagamento escolhida, você coloca o cartão, a sua senha e o sistema emitirá o comprovante via impressora que estará acoplada ao totem.

Nós precisamos lembrar que um Diagrama de Caso de Uso não é feito somente de Casos de Uso, mas também de atores, ou seja, aqueles elementos externos que interagem com o sistema. Assim, eu lhe pergunto: Quais são os atores de um sistema como esse? A resposta é bem simples, o principal ator é você, usuário do sistema que manipulará o sistema diretamente no totem. O segundo ator será a impressora acoplada no totem e que se comunica com o sistema, e o terceiro ator é o equipamento leitor de cartão. É importante destacar que todo tipo de hardware diretamente conectado ao sistema também é um ator no Diagrama de Caso de Uso.

Agora eu lhe pergunto, qual ou quais classes este sistema teria? A resposta também é simples, mas, antes, você deve se lembrar de que uma classe é uma estrutura que armazena dados sobre determinado assunto. Assim, nós precisamos armazenar os dados da sessão, dos produtos disponíveis para compra e do pagamento. Assim, posso lhe dizer que, pelo menos, três classes existirão nem nosso sistema de vendas de ingressos para sessões de cinema.