De que trata o artigo

Este artigo apresenta inicialmente algumas definições básicas sobre a orientação a objetos. Na sequência, é apresentada uma visão geral sobre os diferentes diagramas da UML, entrando em maiores detalhes sobre a elaboração do diagrama de classes através de um exemplo prático.


Para que serve

O que se obtém de principal na modelagem orientada a objetos é a possibilidade de se abstrair diretamente os conceitos do mundo real. Neste contexto, é apresentado o uso da UML através do seu principal diagrama, o diagrama de classes.

Em que situação o tema é útil

Podemos afirmar que é possível se completar a modelagem de um sistema de pequeno ou médio porte, com sucesso, com apenas três diagramas (casos de uso, classes e seqüências). Entender os conceitos da orientação a objetos e conhecer os diagramas da UML é, dessa forma, um importante passo no sentido de ter sucesso nas atividades de desenvolvimento de um projeto.

Elaborar de forma criteriosa diagramas de classes é um fator de sucesso de projetos de software por que, além do fato de ser um momento propenso à inserção de defeitos no software, são neles em que são transformados os problemas do usuário em uma solução computacional, servindo como uma ponte entre requisitos e codificação. Se esta ponte for mal projetada, o software também será.

Neste sentido, o paradigma da orientação a objetos junto com a UML (Unified Modeling Language) apresenta uma série de diagramas para a modelagem de sistemas orientados a objetos. Os diagramas mais comuns são o diagrama de casos de uso (representa as funcionalidades de um sistema), o diagrama de classes (descrtaeve as classes do modelo numa visão estática), o diagrama de seqüência (descrevem as funcionalidades através de uma visão dinâmica) e o diagrama de estados (apresenta o comportamento dinâmico de um objeto).

Neste contexto, o objetivo desta matéria é trazer ao leitor algumas definições iniciais sobre a orientação a objetos e uma visão geral sobre os diferentes diagramas da UML. Ao final é apresentado como elaborar diagramas de casos de uso a partir da descrição de casos de uso.

Orientação a Objetos

Os conceitos da orientação a objetos surgiram da necessidade em se enfatizar unidades discretas, e obter a reutilização de código, mantendo-se a qualidade do software. O núcleo do pensamento OO predomina num foco sobre os dados, em vez dos processos, compondo módulos auto-suficientes — os objetos —, encerrando em sua estrutura todo o conhecimento dos dados e dos processos para manipulação desses dados.

O que se obtém de principal na modelagem orientada a objetos é a possibilidade de se abstrair diretamente os conceitos do mundo real, sem subterfúgios para se chegar à solução computacional.

Os conceitos fundamentais de orientação a objetos são o contrato que estabelece toda e qualquer implementação que se diga OO. Sendo assim, se um desses conceitos não for atendido, não podemos afirmar que determinada tecnologia possa ser nomeada como orientada a objetos.

Vejamos então algumas definições da orientação a objetos:

Objeto: um objeto é qualquer coisa existente no mundo real, em formato concreto ou abstrato, ou seja, que exista fisicamente ou apenas conceitualmente, e o qual se pode caracterizar e identificar comportamentos;

Atributo: as características associadas aos objetos são chamadas de atributos;

Operação x Método: o comportamento dos objetos é representado pelas operações. Contudo, a operação para um objeto representa apenas a definição do serviço que ele oferece a outras estruturas. Quando tratamos da implementação dessa operação, ou seja, da sua representação em código, estamos nos referindo ao seu método;

Mensagem: é a solicitação que um objeto faz a outro, invocando a execução de um determinado serviço;

Encapsulamento: o conceito de encapsulamento nos remete ao fato de que a utilização de um sistema orientado a objetos não deve depender de sua implementação interna, e sim de sua interface. Isso garante que os atributos e os métodos estarão protegidos, só podendo ser acessados pela interface disponibilizada pelo objeto, ou seja, sua lista de serviços;

Herança: ao refinarmos a modelagem de um sistema é comum encontrarmos características redundantes entre objetos. Essa redundância pode ser evitada pela separação dos atributos e operações numa classe comum, identificada como superclasse. Essa classe comum (superclasse) passa a ser a generalização de outras classes que encerram em si apenas os atributos e operações específicos a cada uma;

Polimorfismo: uma operação pode ter implementações diferentes em diversos pontos da hierarquia de classes. Isso significa que ela terá a mesma assinatura (mesmo nome, lista de argumentos e retorno), porém implementações diferentes (métodos). Isso é o polimorfismo.

...
Quer ler esse conteúdo completo? Seja um assinante e descubra as vantagens.
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo