Modelagem UML para Projeto não Orientado a Objetos

Neste artigo vamos abordar alguns diagramas que se adequam num projeto bem simples, mas bem tradicional, vamos modelar sua funcionalidade de tal forma que as vantagens da UML ficarão claras.

Fique por dentro
Artigo do tipo Tutorial
Recursos especiais neste artigo: Artigo no estilo mentoring.

Cenário
Fazer a representação visual de um sistema, ou de uma ideia nem sempre é fácil. Existe uma linguagem apropriada para expressar comportamentos, relações, funcionalidades em um sistema orientado a objetos. A UML. Mas, esse é o ponto, ela possui características específicas para a orientação a objetos. Muito desenvolvedor Delphi foge da UML por achar que, por não utilizar a orientação a objetos em sua totalidade, não precisa modelar ou até mesmo que ela não lhe será útil. Muitos preferem criar um “rabisco” aqui e outro ali e quando não, criar longos manuais descritivos e até mesmo com figuras. Toda essa documentação é criada para facilitar a integração de novos desenvolvedores, para tornar clara a visão de um sistema. O uso de uma linguagem padrão (UML) tem suas vantagens. Por ser um padrão, sua representação não irá variar de uma empresa para outra, assim, um desenvolvedor que já a conheça irá facilmente compreender os diagramas criados e se inteirar da lógica envolvida. Mesmo com aspectos ligados ao paradigma da orientação a objetos, existem alguns diagramas que podem ser utilizados mesmo em softwares procedurais. Neste artigo vamos abordar alguns diagramas que se adequam perfeitamente a essa situação e através de um projeto bem simples, mas bem tradicional, vamos modelar sua funcionalidade de tal forma que as vantagens da UML ficarão claras. São diagramas simples que irão melhorar a comunicação entre sua equipe, irão facilitar o entendimento dos requisitos envolvidos e que irão agregar valor à análise do negócio.

Em que situação o tema é útil
Quando se deseja documentar, coletar requisitos para desenvolvimento de funcionalidades de um software ou quando se deseja compartilhar as regras de negócio e implementações envolvidas em um projeto.

Modelar um software tem o objetivo de tornar mais clara a visualização de suas funcionalidades, componentes, interações, seja para um desenvolvedor ou para um cliente. Ao invés de tentar criar seus próprios símbolos ou identificadores, porque não utilizar algo já consistente e que é um padrão internacional? Esse padrão é a UML.

Temos no Delphi XE3 recursos disponíveis para realizar essa modelagem, não é necessário correr atrás de outro software, tudo o que é necessário encontra-se no IDE. Mas antes de modelar algo, temos um histórico resumido sobre a UML.

Um breve histórico da UML

Sua sigla significa Unified Modeling Language ou Linguagem de Modelagem Unificada. É preciso deixar bem claro que ela não é uma metodologia, processo ou mesmo linguagem de programação. É uma forma padronizada de notação.

Durante os anos 90 existiam vários métodos coexistentes que conflitavam entre si acerca das notações que utilizavam. Os mais conhecidos eram:

  • OMT – Object Modeling Techinique, de Rumbaugh;
  • Método de Booch;
  • OOSE – Object Oriented Software Engineering, de Jacobson.

Em 1995 Booch e Rumbaugh uniram seus processos e notações, eles trabalhavam juntos na Rational Software, que hoje é uma divisão da IBM, e dessa fusão criou-se o Método Unificado. Posteriormente, Jacobson integrou-se a eles, o que resultou em um novo método chamado RUP – Rational Unified Process. Suas notações também foram unidas, gerando a UML.

Pode-se assim dizer que a UML é o resultado da busca pela padronização dos artefatos de análise e projeto, quais sejam: modelos semânticos, sintaxe de notações e diagramas. Sua importância está nos seguintes fatos:"

[...] continue lendo...

Artigos relacionados