Construindo Diagramas de Classes

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? Tenha acesso completo