Engenharia de Software | Linguagem de modelagem unificada (UML) | Paradigma Orientado a objeto

Quando modelamos sistemas usando o paradigma orientado a objeto a tarefa passa a ser a identificação dos objetos do mundo real envolvidos no contexto do sistema e a relação entre esses objetos. Por exemplo, considerando o contexto de um sistema bancário (ilustrado pela imagem a seguir), podemos citar os objetos agencia, cliente e conta, e a relação “Cliente possui uma conta em uma agencia”. Ao identificar os objetos, são identificados também os dados (atributos) e as funcionalidades (funções) inerentes àquele objeto, conforme ilustrado na imagem abaixo. O objeto Cliente possui os dados Nome, Endereço, Telefone e CPF e sobre ele podem ser realizadas, por exemplo, as funções de Incluir Novo Cliente, Excluir Cliente Inativo, Inativar Cliente.

OBJETO = DADOS + FUNÇÕES

Conceituação do modelo OO

Na medida em que são identificados todos os objetos pertinentes a um sistema, já teremos os dados e procedimentos relacionados.

Um modelo Orientado a Objeto (OO) tem como entidade fundamental o objeto, que recebe e envia mensagens, executa procedimentos e possui um estado que, por proteção, apenas o próprio objeto pode modificar. Problemas são resolvidos por meio de objetos, que enviam mensagens uns aos outros.

Os elementos básicos do modelo OO

Um modelo OO é formado por alguns elementos básicos. São eles:

01 – Objetos

É o principal elemento do modelo OO. Os objetos representam as “coisas” a serem modeladas do mundo real. Um objeto pode ser algo concreto como um carro, um aluno ou algo abstrato como uma disciplina. Cada objeto possui os dados inerentes a ele, como por exemplo, Nome (José) e Matrícula (201101272201) de um aluno e possui as operações que ele executa, como incluir novo aluno ou alterar dados de um aluno existente.

02 – Mensagens

As mensagens são enviadas entre os objetos. Quando um objeto deseja que seja executada uma operação, da responsabilidade de outro objeto, ele manda uma mensagem a esse outro objeto informando o que ele deseja que seja feito. A operação desejada será implementada por meio de um método.

03 – Atributos

São dados que caracterizam o objeto.

04 – Métodos

São procedimentos (implementados por uma rotina ou função) que executam uma operação em um objeto e definem parte de seu comportamento.

05 – Classes

São conjuntos de objetos com as mesmas características (atributos e métodos). Por exemplo, os objetos IX35 e Sportage são objetos da classe CARRO, cujas características em comuns são:

• Atributos: modelo, fabricante, ano de fabricação, portas, entre outros.
• Métodos: incluir carro, vender carro etc.

Aqui, um exemplo da diferença entre o conceito de classes e de objetos. Ou seja, é habitual dizermos que o “objeto é uma instância de uma classe”, logo, a classe é o molde e o objeto a “coisa real”.

Os pilares do modelo OO

Dentre as principais características do paradigma orientado a objeto (OO), destacamos:

ENCAPSULAMENTO

Encapsular significa esconder, ou seja, o objeto esconde seus dados (atributos) do acesso indevido de outros objetos e somente permite que eles sejam acessados por operações implementadas pelos seus próprios métodos (funcionalidades que implementam o comportamento do objeto). Com isso, o encapsulamento protege os dados do objeto do uso arbitrário ou não intencional, o que pode ser visualizado na figura apresentada aqui. O encapsulamento é uma técnica para minimizar a interdependência entre as classes, pois apenas os métodos da respectiva classe podem alterar seus dados (atributos), facilitando a identificação de erros e a alteração dos programas.

HERANÇA

Trata-se de um mecanismo para derivar novas classes a partir da definição de classes existentes, que se dá por meio de um processo de refinamento. Uma classe derivada ou descendente herda os dados (atributos) e comportamento (métodos) da classe base ou ancestral ou ascendente. A implementação da herança garante a reutilização de código que, além de economizar tempo e dinheiro, propicia mais segurança ao processo de desenvolvimento, posto que as funcionalidades da classe base já foram usadas e testadas.

Conforme ilustrado na figura abaixo, as classes ContaPoupança e ContaInvestimento herdam da classe Conta, os atributos e métodos que são permitidos.  A classe Conta é chamada Classe base, uma vez que é a base da herança.

POLIMORFISMO

A palavra polimorfismo deriva do grego e significa “muitas formas”. A partir do momento em que uma classe herda atributos e métodos de uma (herança simples) ou mais (herança múltipla) classes base, ela tem o poder de alterar o comportamento de cada um desses procedimentos (métodos). Isso amplia o poder do reaproveitamento de código promovido pela herança, permitindo que se aproveite alguns métodos e se altere (redefina) outros. Dessa forma, um método com mesmo nome, em classes distintas, pode ter diferentes comportamentos. Acompanhe o exemplo da figura apresentada aqui, onde identificamos a seguinte herança: Pagamento em Dinheiro, Pagamento em CC (Cartão de crédito) e Pagamento em Cheque herdam da classe Pagamento o atributo valor e o método Pagar. Observe que em cada classe filha (Pagamento em Dinheiro, Pagamento em Cartão e Pagamento em Cheque) escreve-se novamente o método Pagar. Essa possibilidade ocorre pelo princípio do encapsulamento.

VISIBILIDADE

Outro conceito fundamental é a visibilidade entre as classes. Esta diz respeito ao que uma classe pode visualizar da outra. Como princípio devemos garantir o encapsulamento, ou seja, os atributos devem ser privados (acessíveis apenas por métodos da própria classe) e determinados métodos públicos (acessíveis por todas as classes) devem acessar esses dados. Por outro lado, se mantivermos todos os métodos como privados, a classe perde o sentido, pois nenhuma outra poderá usar seus métodos. Então, devemos usar a visibilidade com equilíbrio e sabedoria. Outra visibilidade possível, além da privada e da pública, é a protegida, onde os atributos e métodos somente podem ser vistos dentro da estrutura de herança, ou seja, pelas classes filhas. Na figura abaixo o atributo Valor e o método Pagar_Conta (Valor : int) da classe Pagamento somente podem ser acessados pelas classes Pagamento em Dinheiro, Pagamento por Cartão e Pagamento em Cheque.

Conclusões do modelo OO

O modelo Orientado a Objeto surgiu (na década de 80) como um modelo promissor para o desenvolvimento de software mais confiável, devido às características inerentes ao modelo de objetos. São elas:

• O conceito de encapsulamento, que permite a construção de classes independentes umas das outras, facilitando o desenvolvimento e a manutenção do software (alterações e melhorias na classe);
• A herança e o polimorfismo, que permitem e facilitam a reutilização de código, úteis nas fases de implementação e manutenção.

O uso de técnicas orientadas a objetos facilita o controle da complexidade, uma vez que promove uma melhor estruturação de seus componentes e também permite que componentes já usados e validados possam ser reaproveitados.

Cabe ressaltar que uma das principais razões para a baixa produtividade no desenvolvimento de software é a dificuldade de reutilização de código usando o paradigma funcional. As hierarquias de classes (herança) são componentes portáveis entre aplicações, que se bem projetados podem ser reutilizados em vários sistemas, sem modificação, e, além disso, podem ser estendidos (polimorfismo) sem corromper o que já existe.

Assim sendo, podemos dizer que o modelo de objetos proporciona modularidade, trazendo os seguintes benefícios:

• Reusabilidade: softwares podem ser escritos com base em componentes já existentes;
• Extensibilidade: novos componentes de software podem ser desenvolvidos a partir de outros já existentes sem afetar o comportamento do componente de origem.

Sabe-se que softwares são intrinsecamente complicados devido aos novos requisitos das aplicações modernas: alta confiabilidade, alto desempenho, desenvolvimento de software rápido e barato, alta complexidade e tamanhos grandes.

O modelo OO veio para combater os problemas derivados da Crise do Software, termo cunhado em 1968, na Europa, e caracterizado pelos seguintes problemas do software: baixa confiabilidade, baixa qualidade, alto custo de manutenção e duplicação de esforços na sua construção (tempo e dinheiro).

Um sistema desenvolvido com as características do modelo OO tende a ser bem estruturado, posto que os objetos são unidades coesas dotados de interfaces simples que escondem as suas implementações.

Conceitos importantes

A orientação a objetos enfatiza a identificação, representação e organização dos objetos necessários a um sistema.

Antes de adentrarmos no universo da análise e do projeto, sob o enfoque do paradigma Orientado a Objeto, vamos tecer rápidos comentários acerca do que sejam as atividades de análise e projeto, dentro do contexto de desenvolvimento de software.

A análise para o desenvolvimento de software

Análise de sistemas significa uma investigação dos problemas e dos requisitos de um contexto, em particular, com vistas ao desenvolvimento de um sistema automatizado. A ideia básica seria identificar quais seriam as funções que esse sistema precisa ter, de forma a atender eficientemente as necessidades de seus usuários.

A atividade de análise, por ser muito abrangente, costuma ser dividida em análise de requisitos (investigação dos requisitos) e análise do domínio do problema.

Relacionando a análise e o projeto

A atividade de projeto denota uma solução, voltada ao atendimento dos requisitos, considerando aspectos de tecnologia. Em geral, o projeto enfoca a arquitetura do sistema, definindo suas partes e as relações entre elas.

A análise pode ser traduzida em “faça a coisa certa” e o projeto em “faça certo a coisa”.

No contexto específico da orientação a objetos, análise implica em identificar e descrever os conceitos, no domínio do problema. Já na atividade de análise, foca-se na definição dos objetos de software e como eles colaboram para que os requisitos dos usuários sejam plenamente satisfeitos.

Um breve histórico da UML

A partir deste ponto, você iniciará com o assunto central de nossa disciplina, a Linguagem de Modelagem Unificada (UML).

A Linguagem de Modelagem Unificada (UML) nasceu da integração de três métodos emergentes orientados a objeto que, na década de 90, eram os mais populares entre os profissionais de desenvolvimento de sistemas:

• O Método OMT (Object Modeling Technique) de Jacobson;
• O Método OOSE (Object-Oriented Software Engineering) de Rumbaugh;
• O Método de Booch.

A UML hoje

Finalmente, em 1997, a UML foi adotada pela OMG (Object Management Group ou Grupo de Gerenciamento de Objetos), como uma linguagem padrão de modelagem.

Atualmente A UML encontra-se em sua versão 2.0 (2.4.1, já existindo a 2.5 em release BETA) e trouxe grandes novidades em relação à estrutura geral da linguagem. Entre as principais se encontram a abordagem de quatro camadas e a possibilidade de se desenvolver “perfis” particulares (oficial no site da OMG em <www.uml.org>).

Desde a versão inicial a UML sofreu mudanças substanciais.

Entendendo melhor a UML

A UML (Unified Modeling Language) é uma linguagem padrão para construção de projetos de sistemas, voltada para a visualização, especificação, construção e documentação de artefatos de um sistema. A UML foi projetada para ser independente do método de desenvolvimento a ser utilizado.

A UML é uma linguagem de modelagem. Não se trata de um método de desenvolvimento, nem tampouco de uma metodologia ou de um processo de desenvolvimento de sistemas. Isso porque ela não determina a ordem e nem como os diagramas devem ser usados. A UML simplesmente disponibiliza os diagramas, sob as várias visões necessárias ao desenvolvimento de sistemas. Cada empresa utiliza-a da forma como lhe convém, ou seja, adequando a linguagem ao seu processo de desenvolvimento de sistema.

Principais características da UML

A UML é uma linguagem destinada à:

• Visualização: a modelagem gráfica tende a facilitar a compreensão, permitindo sua interpretação sem ambiguidades.
• Especificação: permite a construção de modelos precisos, completos e sem ambiguidades. A UML atende a esses quesitos sob o ponto de vista da análise, do projeto e da implementação.
• Construção: os diagramas UML podem ser diretamente integrados a várias linguagens de programação tais como Java e C++.
• Documentação: a UML abrange a documentação da arquitetura do sistema e de todos os seus detalhes.

Os diagramas da atual versão da UML

Os diagramas da UML são divididos em 2 grupos:

1. Diagramas de Estruturas;

2. Diagramas de Comportamentos.

Os diagramas somam um total de 14, conforme demonstra a imagem a seguir.

Veja a seguir a especificação de cada um dos diagramas:

Entenda onde começar com a UML

Nem mesmo os idealizadores da UML conseguem usar todos os diagramas. Geralmente as empresas escolhem um subconjunto deles e implementam nas fases de seus processos de desenvolvimento de sistemas. O ideal é que você encontre o seu conjunto de diagramas que funcione para o tipo de sistema que desenvolve.

Como a UML não determina quais diagramas usar e por onde começar, cada um pode começar por onde desejar. Por exemplo, muitos começam pelo Diagrama de Classes, na medida em que o consideram o mais relevante. Porém, muitos começam pelo Diagrama de Casos de Uso, cuja finalidade é modelar as principais funcionalidades do sistema para atender às necessidades de seus usuários.

Ambos estão usando a UML de forma correta e expressando a forma como visualizam a sequência mais adequada para desenvolver sistemas.

Implementando a UML

Martin Fowler e Steve Mellor propuseram três modos para se usar a UML no desenvolvimento de sistemas.

UML como esboço – o modo mais usado, onde os desenvolvedores usam a UML como forma de expressar aspectos relevantes de um sistema, esboçando ideias e alternativas do que se pretende fazer. É uma possibilidade de discussão com a equipe de desenvolvedores. Seu foco é a comunicação seletiva em vez de especificação completa. Geralmente são usados desenhos informais, sem ferramentas e cujo foco é a discussão de ideias visando à construção de software de forma colaborativa.

O modo UML como esboço está mais compatível com as metodologias ágeis, que preconizam mais código e menos documentação.

UML como projeto – foca a completeza. Aqui a ideia é construir um projeto completo para ser codificado por programadores, valendo-se de ferramentas CASE para melhor entendimento dos modelos, pela equipe.

O modo UML como projeto está mais alinhado com os processos de desenvolvimento mais complexos, como processos iterativos e incrementais, como o PU (processo unificado) implementado através da ferramenta RUP (Rational Unifiec Process).

Obs.: Será esse o tipo de UML abordado em nossas aulas!

UML como linguagem de programação – onde os desenvolvedores desenham os diagramas que são compilados para o código executável e a UML se torna o código-fonte. Exige ferramentas mais sofisticadas.

Por fim, o modo UML como linguagem de programação tende a ser mais usado em modelos de desenvolvimento de prototipação.

O que envolve o processo de desenvolvimento de softwares

Um processo de desenvolvimento de software descreve a abordagem para organizar as atividades relacionadas com a construção, implantação e manutenção de sistemas.

Os processos mais populares hoje são os iterativos, como o PU (Processo Unificado), em particular o RUP (Processo Unificado da Rational) e as metodologias ágeis, como o XP (eXtreming Programming) e SCRUM.

Entenda os processos iterativos

Mas o que são processos iterativos, afinal? São processos onde o ciclo de vida do sistema é dividido em uma série de miniprojetos, curtos, preferencialmente de duração fixa (por exemplo 3 meses), denominados iterações. Cada iteração contém um subconjunto das funcionalidades do sistema.

Em cada iteração temos as atividades de levantamento de requisitos, análise de requisitos, projeto, implementação, testes e implantação, conforme ilustrado pela imagem a seguir.

O ciclo de vida iterativo é baseado em incrementos sucessivos do sistema, pelas iterações do processo. A cada iteração um pedaço do software é incrementado, daí o nome processo iterativo e incremental.

Claro que entre um incremento e outro teremos feedbacks e ajustes na iteração encerrada.

Como já mencionado, a UML não define um processo padrão. Seus autores reconhecem que uma linguagem de modelagem e um processo robusto são importantes. Eles ofereceram sua orientação sobre o que constitui um processo adequado em publicações separadas daquelas exclusivamente dedicadas à UML, porque a padronização de um processo estava fora do escopo da definição de UML.

A UML e os resultados em cada fase

Usar a UML em um processo de desenvolvimento de sistemas não implica, necessariamente, na elaboração de documentos ou uso de uma ferramenta CASE. Muitas equipes usam UML para desenhos à mão em reuniões, para discussão de ideias.

Veja, a seguir, uma proposta de fluxo de trabalho e os resultados em cada fase, usando a UML em um processo iterativo.

Levantamento de Requisitos

• Diagrama de Casos de Uso, para identificação, informal, dos requisitos e funcionalidades do sistema;
• Diagrama de Classes Conceitual, de alto nível, com modelagem apenas das classes, com, talvez, os atributos mais relevantes.

Análise de Requisito

• Casos de uso, que descrevem como as pessoas interagem com o sistema;
• Diagrama de Classes Conceitual;
• Diagrama de Estados, caso seja necessário elucidar algum ciclo de vida de um objeto relevante para o sistema;
• Diagrama de Atividades, com algum fluxo de trabalho relevante, ou um caso de uso mais complexo.

Projeto

• Diagrama de Classes, já a partir de uma perspectiva de software;
• Diagrama de Sequência, para cenários relevantes e comuns;
• Diagrama de Estados;
• Diagrama de Componentes, com a arquitetura do software;
• Diagrama de Implantação, para definição do ambiente físico e distribuição dos componentes.

Nas duas fases primeiras fases (levantamento de requisitos e análise de requisitos), o aspecto mais relevante é a efetiva comunicação com os usuários e com a equipe de desenvolvimento.

Conforme já mencionado, a UML não define uma ordem para elaboração de cada um de seus diagramas. Cada um usa os diagramas da UML da forma como deseja e dentro do processo de desenvolvimento considerado mais adequado à sua equipe e estilo de desenvolvimento, como ficou sinalizado nesta tela, quando identificamos os diagramas que podem (devem) ser modelados em cada fase de qualquer processo de desenvolvimento de software.

APRENDA +

Para saber mais sobre metodologias de desenvolvimento ágil, acesse e leia os conteúdos dos sites indicados:

Desenvolvimento Ágil; http://www.desenvolvimentoagil.com.br/xp/

Desenvolvimento Ágil (SCRUM); http://www.desenvolvimentoagil.com.br/scrum/

Desenvolvimento Ágil (site oficial do SCRUM, em inglês); https://www.scrum.org/

OMG. http://www.uml.org/

Referência

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML, 2/E. 2. ed. Rio de Janeiro: Campus, 2006. cap. 1.

BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML – guia do usuário. 2. ed. Rio de Janeiro: Elsevier, 2005. cap. 1 e 2.

FOWLER, M. UML Essencial. Um breve guia para a linguagem-padrão de modelagem de objetos. 3. ed. Porto Alegre, RS: Artmed, 2005.

Engenharia de Software | Linguagem de modelagem unificada (UML) | Paradigma Orientado a objeto