Aprenda como aplicar a UML em projetos de software orientados a objetos, do design de classes à especificação de interfaces, com exemplos práticos.
Tempo de Leitura: 9 minutos
Introdução
No desenvolvimento de software orientado a objetos, a utilização da UML (Unified Modeling Language) desempenha um papel crucial na documentação e visualização do sistema. Essa linguagem de modelagem facilita a comunicação entre desenvolvedores e stakeholders, garantindo que todos compreendam a estrutura e o comportamento do sistema em desenvolvimento. Em sistemas menores, o design e a implementação podem ocorrer de forma integrada, mas, em projetos maiores, uma fase detalhada de design utilizando a UML é essencial para garantir clareza e organização.
O projeto e a implementação de softwares são atividades que intercalam-se entre si. E o nível de detalhes do projeto depende do tipo de sistema que está sendo desenvolvido e se a abordagem usada é do tipo ágil ou dirigida por um plano. A fase de projeto é a atividade criativa de identificar componentes de software e seus relacionamentos com base nos requisitos de um cliente. Já na implementação, realiza-se o projeto na forma de um programa. Às vezes, existe uma fase de projetos separada, quando o projeto é modelado e documentado. Mas, outras vezes, o projeto pode estar na “cabeça do programador” ou ainda esboçado em uma louça, por exemplo. Tendo em vista que todo o projeto pretende solucionar um problema, sempre haverá um processo de projeto. Todavia, nem sempre se fará necessário ou até adequado descrevê-lo em detalhes usando a UML ou outra linguagem de descrição de projeto. Isso será definido pelas duas circunstâncias citadas anteriormente: tipo de sistema e abordagem de desenvolvimento.
Neste artigo, exploraremos como a UML pode ser aplicada em projetos orientados a objetos, destacando suas principais fases e a importância de sua aplicação em linguagens como Java e C# para melhorar a eficiência e a manutenção do software.
O que é UML?
A UML (Unified Modeling Language), ou Linguagem de Modelagem Unificada, é uma linguagem padrão utilizada para modelar e documentar sistemas de software, principalmente aqueles orientados a objetos. Desenvolvida em meados da década de 1990, a UML surgiu visando criar uma linguagem comum que pudesse ser compreendida por desenvolvedores, analistas e stakeholders, facilitando o planejamento, o design e a manutenção de sistemas complexos.
Essa linguagem utiliza diagramas gráficos para representar a estrutura e o comportamento de um sistema. Com a UML, é possível criar diagramas que mostram, de forma clara, como os diferentes componentes de um software se relacionam e interagem. Ela é amplamente utilizada em processos de desenvolvimento de sistemas orientados a objetos, como aqueles desenvolvidos em linguagens como Java, C# e C++, ajudando a visualizar desde a arquitetura do sistema até os fluxos de interação entre objetos.
Os diagramas UML são divididos em dois grandes grupos:
-
Diagramas estruturais: Focados na organização e estrutura do sistema. Exemplos incluem:
- Diagrama de classes: Mostra as classes do sistema e seus relacionamentos.
- Diagrama de componentes: Representa a arquitetura dos componentes físicos do sistema.
- Diagrama de pacotes: Organiza as classes e os componentes em grupos lógicos.
-
Diagramas Comportamentais: Descrevem como o sistema se comporta durante sua execução. Exemplos incluem:
- Diagrama de casos de uso: Mostra as interações entre usuários (atores) e o sistema.
- Diagrama de sequência: Detalha a ordem das interações entre os objetos.
- Diagrama de estados: Representa as mudanças de estado de um objeto em resposta a eventos.
Esses diagramas oferecem uma visão clara e abrangente do sistema, o que facilita a comunicação entre equipes, o planejamento de futuras expansões e a identificação de possíveis melhorias ou correções. A UML é amplamente adotada em diferentes setores da indústria de software e se tornou um padrão aceito internacionalmente.
Projeto orientado a objetos usando a UML
Um sistema orientado a objetos segue um modelo de desenvolvimento composto por objetos que interagem para manter o seu próprio estado local e fornecer operações nesse estado. A representação desse estado é privada e não pode ser acessada diretamente de fora do objeto. Por isso, os processos de Programação Orientada a Objetos (POO) envolvem a criação de classes de objeto e os relacionamentos entre elas. Essas classes definem os objetos no sistema e suas interações. Todos os objetos possuem dados e operações para manipulá-los. Quando o projeto se realiza como programa executável, os objetos são criados dinamicamente a partir dessas definições de classe.
Sendo assim, podemos entender os objetos como entidades independentes, geralmente, associadas a coisas do mundo real. Por isso é comum haver um mapeamento entre essas coisas reais e os objetos que controlam o sistema, facilitando a compreensão e manutenção do projeto. O projeto de sistema a partir da POO exige, primeiramente, compreender e definir os contextos e as interações externas com o sistema. A partir disso, projeta-se a arquitetura do sistema, identificando seus principais objetos. Então, é possível desenvolver modelos de projetos e especificar interfaces.
Sendo uma atividade criativa, o projeto pode não se apresentar tão sequencial e óbvio. As ideias se desenvolvem a partir de problemas e suas proposições de soluções, passando por refinamentos à medida que mais informações ficam disponíveis. Quando surgem problemas, pode ser necessário voltar atrás e tentar outras opções. A depender do tipo de projeto, usam-se anotações como a UML para esclarecer os aspectos que o sistema terá; em outros tipos de sistemas, utilizam-se anotações informais com maior foco em estimular discussões, por exemplo.
Para visualizar como a UML é empregada em projetos orientados a objetos, utilizaremos como exemplo o desenvolvimento de um software embarcado para uma estação meteorológica na natureza. Imagine que um governo resolveu instalar centenas de estações meteorológicas em áreas remotas e naturais de seu território. Elas ajudarão a monitorar as mudanças climáticas e aumentar a precisão das previsões de tempo. Essas estações fazem parte de um sistema maior: o sistema de informações climáticas que coleta os dados de todas as estações e disponibiliza para outros sistemas para que sejam processados. As estações coletam dados de um conjunto de instrumentos que medem temperatura, pressão, insolação, precipitação, velocidade e direção dos ventos. Assim sendo, o ambiente de estação meteorológica já conta com três sistemas se relacionando:
- Sistema de estação meteorológica: É responsável pela coleta dos dados climáticos, processamento inicial e transmissão para o sistema de gerenciamento (item 2).
- Sistema de gerenciamento e arquivamento de dados: Coleta dados de todas as estações, processa e analisa dados e os arquiva para poderem ser recuperados por outros sistemas, como sistemas de previsão meteorológica.
- Sistema de manutenção de estação: Comunica-se via satélite com todas as estações na natureza para monitorar a condição desses sistemas e fornecer relatório de possíveis problemas. Também pode atualizar o software embarcado nesses sistemas. Em caso de problemas de sistema, ele pode ser utilizado para controlar remotamente a estação meteorológica.
Em um primeiro diagrama representando essas relações, teríamos:
Contexto do sistema e interações
O primeiro passo no estágio de projeto de software é compreender os relacionamentos entre o software sendo projetado e seu ambiente externo. Este ponto é essencial para planejar como o sistema se comunicará com seu exterior e quais as funcionalidades que devem ser empregadas para tal, além de definir seus limites. No caso em estudo, é preciso definir como a funcionalidade será distribuída entre o sistema de controle para todas as estações e o software embarcado na própria estação.
Modelos de contexto do sistema e os modelos de interação apresentam visões complementares dos relacionamentos entre um sistema e seu ambiente. Quanto aos modelos de contexto do sistema, é um modelo estrutural que apresenta os outros sistemas no ambiente do sistema que está sendo desenvolvido. Já os modelos de interação é um modelo dinâmico que mostra como o sistema interage com seu ambiente a medida em que é utilizado.
Quanto ao primeiro tipo, ele pode ser representado por meio de associações que mostram simplesmente que existem alguns relacionamentos entre as entidades envolvidas. É possível documentar o ambiente do sistema usando o diagrama de bloco simples que mostra as entidades no sistema e suas associações, segue um exemplo abaixo:
Ao modelar as interações de um sistema com o seu ambiente, deve-se usar uma abordagem abstrata que não exagere em detalhes, priorizando a clareza da representação. Se quisermos incluir mais informações sobre o ambiente e suas interações, podemos utilizar o “modelo de caso de uso”. Nele, cada possível interação é identificada como uma elipse e a entidade externa envolvida na interação é representada por um boneco de palito, seguindo o exemplo abaixo:
Cada um desses casos de uso deve ser descrito em linguagem natural e estruturada. Dessa maneira, os projetistas podem identificar os objetos no sistema e compreender suas funções. A modelagem dos sistemas embarcados frequentemente ocorre a partir da descrição de como eles respondem a estímulos internos ou externos. Portanto, os estímulos e as respostas associadas devem ser apresentados na descrição. Vamos dar um exemplo tomando como referência o caso de uso “Informar clima”:
|
Sistema |
Estação meteorológica |
|
Caso de uso |
Informar clima |
|
Atores |
Sistema de informações meteorológicas, estação meteorológica |
|
Dados |
A estação envia para o sistema um resumo dos dados coletados pelos instrumentos em determinado período. Os dados enviados são: a máxima, a mínima e a média de temperatura do solo e do ar; a máxima, a mínima e a média das pressões atmosféricas e das velocidades dos ventos; a precipitação total; a direção dos ventos, conforme amostrado a cada 5 minutos. |
|
Estímulo |
O sistema de informações meteorológicas estabelece uma comunicação via satélite com a estação e solicita a transmissão de dados. |
|
Resposta |
Os dados resumidos são enviados para o sistema de informações meteorológicas. |
|
Comentários |
Normalmente, a solicitação de informações às estações meteorológicas ocorre a cada hora. Porém, essa frequência pode variar de uma estação para outra e pode ser modificada no futuro. |
Projeto de arquitetura
Definidos o contexto do sistema e suas interações, as informações definidas podem ser utilizadas como base do projeto de arquitetura. Com os principais componentes e relações identificados, organiza-se a arquitetura utilizando um padrão, como em camadas ou cliente-servidor. Isso demandará conhecimentos gerais dos princípios de projeto da arquitetura em conjunto com o domínio da aplicação.
Abaixo, está o projeto de alto nível de arquitetura do software de estação meteorológica. A estação é constituída por subsistemas autônomos que se comunicam transmitindo mensagens em uma infraestrutura comum: o Canal de Comunicação. Cada subsistema “escuta” as mensagens no canal e seleciona as que são destinadas a ele. Esse “modelo ouvinte” (listener) é uma arquitetura frequente em sistemas distribuídos. Uma das vantagens do listener é a facilidade de permitir diferentes configurações de subsistemas, uma vez que o emissor não precisa endereçar a mensagem para um subsistema específico.
Identificação de classes
Legenda: Na prática da definição de classes, deve-se empregar várias fontes de conhecimento para defini-las, assim como seus atributos e operações do objeto. | Imagem: Freepik
Nessa etapa de projeção, já é possível ter algumas ideias a respeito dos objetos essenciais no sistema. Conforme o projeto se torna mais definido, também podemos refinar os objetos e suas características. Por exemplo, no caso de uso “Informar Clima”, imediatamente imagina-se a necessidade de criar objetos para representar os instrumentos de coleta de dados e os resumos dos dados climáticos.
Há várias maneiras de identificar a necessidade de classes, seguem algumas sugestões:
- Analisar os substantivos, adjetivos e verbos envolvidos nos processos. Exemplo: Um cliente pode logar no sistema e imprimir seu boleto de cobrança. Temos o cliente e o boleto como substantivos além do próprio sistema. Logo, é possível ser necessário criar uma classe Cliente e Boleto. O cliente terá atributos (adjetivos) como CPF, nome, email e telefone. Já os verbos costumam sugerir métodos da classe: logar no sistema, imprimir boleto…
- Observar entidades tangíveis (coisas) no domínio da aplicação: aluno, professor, curso, disciplina, supondo um sistema para gestão de universidades.
Na prática da definição de classes, deve-se empregar várias fontes de conhecimento para defini-las, assim como seus atributos e operações do objeto. Os documentos de requisitos são uma fonte rica de informações, assim como discussões com os usuários e as análises de sistemas já existentes. Também pode ser preciso projetar “objetos de implementação” que serão usados para fornecer serviços gerais como buscar e validar dados.
No caso da estação meteorológica na natureza, a identificação dos objetos se baseia no hardware tangível do sistema. Temos, então, o termômetro do solo, anemômetro e barômetro como objetos do domínio da aplicação. Enquanto os objetos EstaçãoMeteorológica e DadosMeteorológicos podem ser identificados a partir da descrição do caso de uso. O foco desta etapa é na definição dos objetos e sua implementação, podendo ser interessante observar características em comum e elencar hierarquia entre as classes.
A representação da classe de cada objeto pela UML conta com o nome da classe, seus atributos e métodos, como no exemplo:
Modelos de projeto UML: estrutural e dinâmico
Os modelos de projeto são a ponte entre os requisitos do sistema e a sua implementação. Isso porque eles mostram os objetos do sistema com todas as suas associações e relações. Além disso, eles também devem incluir detalhes suficientes para permitir que os programadores decidam como será a implementação. O nível de detalhamento de cada modelo depende do processo utilizado. Os modelos abstratos podem ser suficientes quando há um vínculo próximo entre engenheiros de requisitos, projetistas e programadores. Entretanto, se for utilizado um processo de desenvolvimento dirigido por um plano, talvez seja necessário obter modelos mais detalhados, sobretudo se o vínculo entre envolvidos no projeto for distante.
Usando a UML, há dois modelos a serem desenvolvidos:
- Modelos estruturais: descrevem a estrutura estática do sistema com suas classes e relações.
- Modelos dinâmicos: descrevem a estrutura em ação, com interações previstas em tempo de execução entre os objetos do sistema.
Há 13 modelos de projeto definidos pela UML, mas 3 em especiais são mais utilizados: Modelos de Subsistema, Modelos de Sequência e Modelos de Máquinas de Estados.
Especificação de interfaces
Nesta fase, definem-se as interfaces para que os objetos e os subsistemas possam ser projetados em paralelo. Dessa forma, determinamos as assinaturas e semânticas dos serviços fornecidos pelo objeto ou um grupo de objetos. A especificação das interfaces ocorre usando a mesma notação de um diagrama de classes pela UML. Note que as interfaces não possuem atributos, apenas métodos que permitem acessar e atualizar dados. Como a representação de dados fica “escondida”, ela pode ser facilmente modificada sem afetar os objetos que usam esses dados.
Conclusão
A UML se destaca como uma ferramenta essencial para o desenvolvimento de software orientado a objetos, oferecendo uma forma clara e visual de estruturar projetos complexos. Ao longo deste artigo, abordamos as principais etapas do uso da UML, desde a definição do contexto e das interações do sistema até a identificação de classes e a especificação de interfaces. Esses modelos não apenas facilitam o entendimento do sistema, mas também ajudam a manter a organização e a escalabilidade do projeto, especialmente em ambientes de desenvolvimento colaborativo.
Embora este artigo tenha introduzido os conceitos fundamentais, o estudo da UML é vasto e contínuo. Aprofundar-se em suas diversas técnicas e diagramas pode trazer ainda mais benefícios na documentação e na manutenção de seus projetos. Se você deseja seguir aprendendo sobre boas práticas de design de software e UML, não deixe de acompanhar nossos próximos artigos e de se inscrever no blog para receber atualizações.
