A apresentação gráfica de um programa orientado a objeto é um artifício que facilita a entendimento das entidades do programa e suas relações. A linguagem gráfica para modelagem de problemas via orientação a objetos mais aceita é a Unified Modeling Language (UML).
A UML surgiu da união de três metodologias de modelagem: o método de Booch, de Grady Booch, o método Object Modeling Technique (OMT), de Ivar Jacobson e o método OOSE (Object-Oriented Software Engineering), de Jim Rumbaugh. Essas eram as três metodologias de modelagem orientada a objetos mais populares entre os profissionais da área de engenharia de software até meados da década de 1990. A união dessas metodologias contou com o amplo apoio da Rational Software, que também financiou o projeto. Em 1997, a Object Management Group (OMG) adotou a UML como padrão de modelagem e se encarregou do seu desenvolvimento (Guedes, 2005).
“A UML é bem mais ampla do que uma ferramenta para visualização da arquitetura de um programa orientado a objetos. Segundo seus desenvolvedores (Booch, Rumabaugh e Jacobbson), a finalidade da UML é proporcionar um padrão de planejamento de arquitetura de projetos de sistemas, incluindo aspectos conceituais, como processos de negócios e funções de sistema, além de itens concretos, como as classes escritas em determinada linguagem de programação, esquemas de bancos de dados e componentes de software reutilizáveis” (Apud Medeiros, 2004).
A UML não indica a codificação do programa em si, sendo um artifício para modelagens num nível mais alto. Dessa maneira, a UML não está vinculada a nenhuma linguagem, sendo possível usá-la, inclusive, para linguagens de programação que não suportem implicitamente o paradigma de orientação a objetos. Essa visão mais ampla também permite que a UML seja acessível aos não programadores. Isso facilita uma maior inclusão do usuário final no processo de programação quando esses não são programadores. “Em geral, será necessária
uma documentação adicional para se sair do diagrama e se chegar efetivamente ao código, porém, essa comunicação deve ser minimalista. Uma documentação extensa nessa passagem pode, inclusive, ser um indício de que a diagramação deve ser revisada” (Medeiros, 2004).
A UML, na sua versão 2.0, consta de 14 diagramas. A multiplicidade de diagramas permite várias visões do problema, sendo os diagramas, portanto, complementares entre si. Porém, é comum os diagramas possuírem áreas de sobreposição. A sobreposição é útil para a detecção de erros na modelagem (Guedes 2005). Porém, não é necessário construir os 14 diagramas para se realizar uma análise utilizando a UML.
Para o presente trabalho, limitar-se-á aos Diagramas de Classe e ao Diagrama de Seqüência. Embora outros diagramas possam ser úteis para a representação da expansão feita, os dois diagramas citados são suficientes para dar uma visão geral do trabalho.
3.3.1 Diagrama de Classes
A Figura 3.2(a) mostra a representação de uma classe na UML. O diagrama pode ser dividido em até três partes. Na primeira divisão coloca-se o nome da classe. Na segunda divisão, coloca-se o nome dos campos, e na última divisão, os operadores (métodos) dessa classe. O símbolo que precede o nome do campo ou do método indica a sua visibilidade: ‘-‘ para privado, ‘#’ para protegido e ‘+’ para público. No caso dos campos da classe, o tipo de campo é colocado após o nome do mesmo. Para os métodos, escrevem-se os parâmetros de chamada e o tipo retornado pela chamada do mesmo.
Os métodos abstratos são anotados em itálico. Para a interface - Figura 3.2(b) - isso não é necessário pois todos os métodos são abstratos.
FIGURA 3.2: Exemplos de diagrama de classe na UML
Algumas classes possuem vários métodos e campos, não sendo prático escrever todos eles no diagrama. Limita-se, então, a escrever os campos e métodos mais relevantes da classe.
Em algumas linguagens de programação orientada a objetos, existe também o recurso dos pacotes que permitem organizar classes afins que não se relacionam pelo mecanismo de herança. Embora possa haver classes dentro de um pacote que não se relacionam por herança, a herança só é possível dentro de um mesmo pacote. A Figura 3.3 mostra um exemplo de pacote contendo uma classe e uma interface.
FIGURA 3.3: Exemplo de pacote
FIGURA 3.4: Exemplo de herança
Um exemplo de herança é mostrado na Figura 3.4. O sentido da seta é obrigatório para indicar o sentido da herança. A Figura 3.5 mostra algumas relações possíveis entre classes. Essas relações são descritas na Tabela 3.1. Porém, o tipo de relacionamento entre as classes pode ser bem vasto, de modo que poucos casos possuem uma diagramação específica. Nos demais
casos, pode se utilizar o recurso dos estereótipos que consiste da anotação da relação dentro dos sinais “<< >>”. O emprego dos estereótipos não se limita a explicar relações de classes, sendo utilizados para detalhar qualquer relação em qualquer dos diagramas UML. Mesmo quando se tem uma diagramação específica para demonstrar a relação, os estereótipos podem ser utilizados para prover informações adicionais.
FIGURA 3.5: Exemplo de relações entre classes
TABELA 3.1: Relações entre as classes mostradas na Figura 3.5
CLASSES
RELACIONADAS RELAÇÃO COMENTÁRIO
1 e 2 Dependência Alguma funcionalidade da classe 1 depende de
uma funcionalidade disponível na classe 2
1 e 3 Agregação A classe 1 agrega objetos da classe 3.
CLASSES
RELACIONADAS RELAÇÃO COMENTÁRIO
3 Associação unária
ou reflexiva.
Algum caso de associação ocorre entre objetos da mesma classe
3 e 4 Composição Objetos da classe 4 compõem algum objeto da
classe 3.
4, 5 e 6 Colaboração A associação das classes 4 e 5 tem uma
colaboração por parte da classe 6.
4 e 5 Associação
A associação entre as classes 4 e 5 não se enquadra dentro de outras formas de associação. Geralmente, a natureza da associação é explicada com o uso de estereótipo.
A Figura 3.6 mostra um diagrama de classes bastante completo. Nessa figura também é mostrada a anotação da multiplicidade da relação. A multiplicidade indica quantas instâncias de uma classe se relacionam com a classe instanciadora. A Tabela 3.2 explica as relações de multiplicidade da Figura 3.6.
TABELA 3.2: Relações de multiplicidade da Figura 3.6