C URSO P ROFISSIONAL T ÉCNICO DE G ESTÃO E P ROGRAMAÇÃO DE S ISTEMAS I NFORMÁTICOS P...

CURSO PROFISSIONAL TÉCNICO DE GESTÃO E PROGRAMAÇÃO DE SISTEMAS INFORMÁTICOS

PROGRAMAÇÃO E SISTEMAS DE INFORMAÇÃO11º ANO

Módulo 12 – Introdução aos Sistemas de Informação

Diagrama de Classes

Ano lectivo 2013/2014

NOTA HISTÓRICA

Ao longo dos anos foram propostas e utilizadas diversas técnicas e linguagens de auxílio à estruturação de informação. Actualmente o Modelo Relacional, divulgado nos anos 80, ainda é a forma privilegiada de estruturar informação.

Como complemento, a linguagem UML (Unified Modelling Language), criada em 1997, tem sido largamente utilizada para auxiliar o desenho de modelos relacionais.

UNIFIED MODELLING LANGUAGE (UML)

A UML é uma linguagem para especificações de sistemas.

É uma linguagem diagramática, ou seja, as especificações podem ser representadas através de diagramas que recorrem a um conjunto simples de símbolos gráficos.

DIAGRAMAS DE CLASSES - DEFINIÇÃO

O Diagrama de Classes é um dos diagramas da linguagem UML e está vocacionado para representar a estrutura da informação que suporta um sistema de informação.

Permite desenhar uma base de dados relacional de forma a que o desenho seja mais facilmente entendido por um profissional não informático.

DIAGRAMA DE CLASSES – NOÇÕES BÁSICAS

Para perceber como construir um Diagrama de Classes há que dominar os seguintes conceitos:

ObjectoClasseRelação

OBJECTO - DEFINIÇÃO

Considera-se que um objecto é qualquer coisa relevante, que se distingue das outras, caracterizado por um conjunto de atributos e sobre o qual podem ser executadas acções.

E o que é ser relevante?

OBJECTO - RELEVÂNCIA

Por exemplo, uma mesa é algo que possui um conjunto de atributos (peso, cor, material de fabrico, etc.) e sobre a qual podem ser executadas acções (comprar, vender, reparar, etc.).

Podemos considerar que as mesas se distinguem umas das outras através de um código de barras preso a cada mesa.

OBJECTO - RELEVÂNCIA

No entanto, embora as mesas tenham atributos e possam ser executadas acções, as mesas não são relevantes para, por exemplo, um sistema de processamento de vencimentos numa organização.

OU SEJA

As mesas não são objectos do sistema de vencimentos porque não são relevantes para este sistema.

OBJECTO - RELEVÂNCIA

As mesmas mesas já poderão ser relevantes para uma aplicação destinada à gestão do inventário da mesma organização, ou seja, seriam objectos desse sistema.

Os objectos não têm que representar necessariamente coisa com existência física. Os departamentos de uma organização podem ser relevantes para um sistema de informação e, no entanto, não têm representação física, são conceitos abstractos.

OBJECTO - DISTINÇÃO

A possibilidade de um sistema de informação poder distinguir um objecto dos restantes é importante.

Um objecto deverá ser distinto dos restantes através de atributos relevantes para o sistema que o armazena.

OBJECTO - EXEMPLO

O cliente João Silva é um objecto do sistema de informação, caracterizado pelos atributos nome, morada e ncontribuinte e sobre ele podem ser executadas operações tais como: emitir facturas, alterar dados pessoais, aceitar encomendas, etc.

O João Silva é distinto dos restantes elementos do sistema de informação .

Objecto “João Silva”

CLASSE - DEFINIÇÃO

A Classe é uma descrição de um conjunto de objectos semelhantes, ou seja, objectos que partilham os mesmos atributos, sobre os quais podem ser executadas as mesmas operações (comportamento) e que representam a mesma realidade.

A classe Cliente representa todos os clientes (objectos) porque todos eles podem ser caracterizados pelos mesmos atributos e ter o mesmo comportamento, e representam a mesma realidade.

CLASSE - ATRIBUTOS

Poderão existir atributos que não são relevantes para um subconjunto de objectos.

Por exemplo, sobre aos alunos dos cursos profissionais poderá ser pertinente guardar o local de estágio. Apesar de esse atributo nunca ser preenchido nos objectos que representam os outros alunos, poderemos optar por ter uma única classe para todos os alunos.

CLASSE - IDENTIFICADOR

É também necessário que o mecanismo que permite identificar um objecto de uma classe seja válido para todos os objectos dessa classe.

Por exemplo, não é possível ter, na mesma classe um conjunto de clientes identificados pelo número de contribuinte e os restantes identificados por um número interno de identificação.

CLASSE – REPRESENTAÇÃO GRÁFICA

Cliente

NomeMoradaNúmero Contribuinte

Nome da classe, único no diagrama

Atributos, nome único dentro da classe

CLASSE - EXEMPLO

A classe Cliente representa todos os clientes do sistema de informação que partilham: os mesmos atributos

(nome, morada e ncontribuinte),

o mesmo mecanismo de identificação (ncontribuinte),

sobre os quais podem ser executadas as mesmas operações (emitir facturas e aceitar encomendas) e

a mesma realidade.Classe “Cliente”

RELAÇÃO

Os objectos não vivem isoladamente num sistema de informação, pelo contrário, eles relacionam-se com outros objectos, inclusivamente com objectos de outras classes.

Um cliente, por exemplo, relaciona-se com as facturas que lhe são emitidas. Um funcionário relaciona-se com o seu departamento.

RELAÇÃO

É invulgar encontrar objectos que, num sistema de informação, não se relacionem com objectos de outras classes.

Um Diagrama de Classes consiste essencialmente na representação do relacionamento entre classes.

A UML contempla dois tipos de relações: Associações e Generalizações

RELAÇÃO - ASSOCIAÇÃO

Representam as ligações existentes entre os objectos das classes.

Representação gráfica de uma associação:

Cliente

NomeMoradaNúmero Contribuinte

Factura

DataValorNúmero Factura

Facturação Cliente

1..1 0..*

RELAÇÃO – CLASSIFICAÇÃO DE ASSOCIAÇÕES

Um para muitos

Departamento

SiglaDesignação

Funcionário

NomeMorada

Trabalha

1..1 1..*

RELAÇÃO – CLASSIFICAÇÃO DE ASSOCIAÇÕES

Muitos para muitos

Associação

SiglaDesignaçãoMorada

Associado

Número SócioNomeData Admissão

Sócio

0..* 0..*

RELAÇÃO – CLASSIFICAÇÃO DE ASSOCIAÇÕES

Um para um

Encomenda

Número EncomendaDataValorData Entrega

Factura

Número FacturaDataValor

Factura Encomenda

1..1 0..1

RELAÇÃO – CLASSES ASSOCIATIVAS

À semelhança das classes, as associações também podem ser caracterizadas por atributos.

Por exemplo: Numa encomenda podem ser encomendados vários produtos, assim como um produto pode constar em várias encomendas.

RELAÇÃO – CLASSES ASSOCIATIVAS

No diagrama apresentado não é possível representar a quantidade de produtos encomendados.

Encomenda

Número EncomendaDataValorData Entrega

Produto

CódigoDesignaçãoPreço

Produtos encomendados

0..* 0..*

RELAÇÃO – CLASSES ASSOCIATIVAS

O atributo quantidade não caracteriza os produtos (se assim fosse, todas as encomendas teriam sempre a mesma quantidade do produto) nem as encomendas (se assim fosse, numa encomenda seria encomendada a mesma quantidade de todos os produtos).

A quantidade caracteriza a associação, e deverá ser representada como um atributo dessa associação.

RELAÇÃO – CLASSES ASSOCIATIVAS

Quando uma associação é caracterizada por atributos (tornando-se uma classe associativa), é obrigatório atribuir um nome à associação (o nome da associação não fica sobre a linha, mas dentro do rectângulo que representa a classe associativa).

Encomenda

Número EncomendaDataValorData Entrega

Produto

CódigoDesignaçãoPreço

0..* 0..*

Produtos encomendados

Quantidade

RELAÇÃO – ASSOC. COM A PRÓPRIA CLASSE

Embora não seja muito frequente, por vezes surge a necessidade de associar objectos de uma classe a outros da mesma classe. Exemplo:

Funcionário

NúmeroNomeFunção Sup. Herárquico

0..*

0..1

Subordinado

Chefia

BIBLIOGRAFIA Desenhar Bases de Dados com UML (1ª

edição), da editora Edições Sílabo, da autoria de Pedro Nogueira Ramos, 2006