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.
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.
Resumo DevMan
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á.
O diagrama de classes da UML 2.0 é o principal elemento nas atividades de análise e projeto de softwares orientados a objetos. O digrama de classes apresenta as classes do sistema, seus relacionamentos (incluindo herança, agregação e associação), e as operações e atributos de cada classe.
O diagrama de classes pode ser utilizado em diferentes situações incluindo a modelagem conceitual e de domínio e o projeto detalhado do sistema. Neste sentido, este artigo irá apresentar os conceitos por trás deste diagrama da UML e também apresentará como devemos proceder para criar diagramas de classes em nossos projetos em nível conceitual.
Diagramas de classes conceituais
A Figura 1 apresenta uma visão inicial de um simples diagrama de classes da UML no contexto de um modelo conceitual para uma universidade. Perceba que por se tratar de um modelo conceitual ou de domínio, apenas os principais conceitos associados ao domínio do problema assim como seus relacionamentos estão representados.
Neste modelo, conforme podemos observar, as classes são representadas por estruturas retangulares divididas em três áreas cada. A área superior é o local onde definimos o nome da classe. A área intermediária é o local onde definimos os atributos das classes. Por fim, na parte inferior definimos as operações úteis para a classe em questão. Perceba que ao definirmos atributos e operações já estamos tomando algumas decisões de projeto durante a modelagem conceitual, o que em teoria poderia ser evitado.
No caso de se optar por não definir os atributos e operações neste momento, pode-se representar as classes através de retângulos divididos em duas áreas. Na área superior mantemos o nome da classe, enquanto que na área inferior definimos as responsabilidades associadas às classes. Além disso, como outra alternativa para a representação dos modelos conceituais, poderíamos ter neste momento apenas as classes com seus respectivos nomes e, naturalmente, seus relacionamentos.
Entretanto, estas duas últimas abordagens podem não se tornar muito úteis na prática. Por conta disso, faremos uso neste artigo daquilo que entendemos como sendo o mais interessante em termos de modelagem conceitual em projetos de software.
Figura 1. Visão inicial do diagrama de classes.
Observando o diagrama de classes da Figura 1, temos que o elemento Enrollment é uma classe associativa, também chamada classe de ligação. Este tipo de classe é usado para modelar associações que possuem necessidades de ter métodos e atributos. É importante também estarmos atentos ao fato de classes associativas serem normalmente modeladas durante a modelagem conceitual e serem representadas durante fases mais avançadas do desenvolvimento de uma forma diferente, conforme podemos observar na ...
