Artigos Delphi Modelagem UML para Projeto não Orientado a Objetos
Por que eu devo ler este artigo: 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:

  • Serve como linguagem para expressar decisões que nem sempre são fáceis de ver apenas olhando para o código;
  • Fornece semântica para capturar decisões estratégicas e táticas do projeto;
    • ...
    Quer ler esse conteúdo completo? Tenha acesso completo