Para pessoas não desenvolvedoras, o desenvolvimento de ‘software’ é algo por vezes envolto num ar de complexidade e dificuldade, e para algumas pessoas desenvolvedoras é algo difícil de explicar além do “eu construo programas/apps/sites, etc.”.
Como pessoas desenvolvedoras, o nosso trabalho está mais ligado a área de humanas do que exatas, não que seja desnecessário fazer cálculos complexos ocasionalmente, mas o grosso do trabalho é a abstração do mundo ao nosso redor.
O termo abstração por si nem é nada exclusivo da nossa área, é algo inerente a todos os seres humanos. Quando você precisa descrever qualquer coisa para uma pessoa você usa abstração.
Por exemplo, se tiver que descrever um paciente, você provavelmente vai descrevê-lo dentro do contexto que está, por exemplo:
- Para a área médica você provavelmente descreveria ele citando o nome, sexo, idade, altura, histórico médico, etc,
- enquanto para a área financeira responsável por cobrar dito paciente você provavelmente usaria o nome, documento de identidade (ex. CPF, RG), valor do tratamento/exames utilizados para cobrança, plano de saúde do paciente (se tiver).
Visualizamos que embora o Paciente seja uma pessoa, para cada área ele é representado de uma forma, nós chamamos isso de abstração e algumas pessoas chamam estes contextos de domínios.
Introdução a Modelagem
Pessoas desenvolvedoras traduzem essas abstrações em modelos, utilizados para organizar o funcionamento do ‘software’.
O ‘software’ por sua vez pode ser construído usando diversos paradigmas de programação, mas o mais fácil de visualizar a modelagem é o da Programação Orientada a Objetos.
Na programação orientada a objetos, nós modelamos as abstrações em “objetos” dentro dos nossos programas, para isso nós trazemos a abstração que faz sentido dentro do contexto do problema de negócio que tentamos resolver.
Voltando ao exemplo do paciente, ao desenvolver um sistema de cobrança para um hospital, pode não fazer sentido ter informações como tipo sanguíneo, ou se o paciente é doador de orgãos para a pessoa que vai fazer a cobrança emitir a fatura, mas é necessário ter a identificação exata da pessoa e dos serviços por ela utilizado para a coleta de impostos e emissão da nota fiscal.
Modelos Tangíveis e Intangíveis
Outro ponto que pode confundir pessoas não desenvolvedoras, é que objetos não precisam ser objetos tangíveis, ou seja, não precisam ter um corpo físico.
Por exemplo, um prazo de entrega, um placar de uma partida, ou mesmo a posição espacial de um objeto via GPS são intangíveis, mas ainda assim podem ser modeladas como objetos quando falamos de programação.
A programação orientada a objetos nesse sentido não visa traduzir apenas os objetos “reais” para dentro do ‘software’, mas também os conceituais, por assim dizer.
Tenho objetos e agora?
Até o momento a ideia de modelagem apresentada focou muito no que os objetos tem ou são, mas isso é apenas uma das dimensões de um objeto.
Normalmente associamos duas dimensões aos objetos:
- Estado: O que os objetos são (ou o estado em que estão).
- Ação: O que os objetos podem fazer.
O estado é o conjunto de propriedades que um objeto tem num determinado período, pensando num objeto paciente poderíamos ter algo como:
- Cliente: Rafael
- Situação: Aguardando Triagem
- Temperatura: 37ºC
- Batimentos: 60bpm
- Pressão Sanguínea: 12/8
- Fraturas: Nenhuma visível
- Urgência para atendimento: A definir
- Profissional para atendimento: A definir
E após passar pela triagem ter o estado mudado para:
- Nome: Rafael
- Situação: Aguardando atendimento
- Temperatura: 37ºC
- Batimentos: 60bpm
- Pressão Sanguínea: 12/8
- Fraturas: Nenhuma visível
- Urgência para atendimento: Amarelo
- Profissional para atendimento: Clinico Geral
O estado nesse sentido, repito, é o conjunto das propriedades do objeto, ou seja, no exemplo, nome, situação, etc juntos são o estado do paciente.
As ações na maior parte das linguagens de programação orientadas a objetos, são chamadas de métodos, e os métodos são responsáveis por alterar o estado da aplicação.
Voltando ao nosso exemplo, nós podemos ter um objeto chamado ServiçoTriagem, esse objeto tem um método chamado triagem(paciente), e esse método faz a triagem do paciente.
Durante a triagem o ServiçoTriagem nesse nosso exemplo, recebe um paciente, e acessa as suas propriedades, para determinar o nível de gravidade do caso, e dessa forma garantir que o paciente seja atendido num período adequado pelo profissional adequado.
O serviço de triagem pode ter regras de negócio, que definem qual é o profissional que deve atender, e com qual urgência o paciente deve ser atendido.
Algumas possíveis regras seriam:
- Possui trauma (ex. Fratura)
- Se exposta: Profissional Ortopedista, Urgência Vermelha (Muito Urgente)
- Se interna: Profissional Ortopedista, Urgência Laranja (Urgente)
- Possui Febre alta, taquicardia ou pressão alta/baixa: profissional Clinico geral, Urgência Vermelha (Muito Urgente).
- Possui Febre baixa: Profissional Clinico geral, Urgência Laranja (Urgente)
- Não possui febre, apenas tosse: Profissional Clinico geral, Urgência Amarela (Não Urgente)
- etc.
Nesse cenário o objeto paciente pode expor um método definirUrgenciaEProfissional(urgencia, profissional), que seria chamado pelo serviço, passando a urgencia e o profissional adequado ao estado, e quando chamado a situação do paciente mudaria para aguardando atendimento.
Olhando assim parece bobo, mas é como um programa é normalmente construído.
Classes e objetos
Outro conceito que temos quando falamos de programação orientada a objetos são classes e objetos, e a forma mais simples de explicar isso é a seguinte:
- Classes são para objetos como plantas baixas são para construções, uma planta baixa define, por exemplo, que uma casa tem uma sala, cozinha, banheiro e quarto de x metros quadrados.
- Objetos são a manifestação das classes (chamamos instâncias em programação), nesse exemplo, pense que você tem duas casas com a mesma planta, mas a casa A tem uma geladeira duplex e um fogão de 6 bocas na cozinha, e a casa B tem uma geladeira de porta francesa com um cooktop de indução.
Nesse exemplo, embora as casas tenham a mesma planta (sejam da mesma classe), elas têm eletrodomésticos diferentes, ou seja, estados diferentes.
E mesmo que tivessem o mesmo tipo e modelo de eletrodomésticos, ainda seriam diferentes, porque a casa A teria a geladeira do senhor A, e a casa B a geladeira do senhor B.
Ferramentas visuais/linguagem de modelagem
Não vamos nos aprofundar, os profissionais podem usar as ferramentas que quiserem para modelar, podem usar desde papel e lápis, até ferramentas visuais.
A comunidade de desenvolvimento adotou certas práticas ao longo do tempo, para a anotação destas modelagens, a mais conhecida e difundida é a UML que define um conjunto de regras para vários tipos de modelagem (não apenas objetos, mas interações, estados, etc).
Um exemplo de modelagem UML pode ser visto abaixo:
Mas também pode ser espressado da seguinte forma:
No segundo exemplo, o diagrama apresenta as propriedades e métodos, sendo apresentado o nome da classe na primeira caixa, as propriedades na segunda, e os métodos na terceira. A classe de urgência, por exemplo, não tem métodos, por isso só tem seu nome e propriedades.
É importante saber que não existe uma regra definida do que é certo ou errado, a modelagem é certa quando atende a regra de negócio, e programas (com algumas exceções) quase sempre permitem atualizações.
Considerações
Esse é um texto bem introdutório, escrito numa linguagem bem simples, para apresentar de forma introdutória os conceitos de abstração e modelagem para pessoas não desenvolvedoras.
Por isso vários conceitos foram simplificados, e vários detalhes foram omitidos.
