Upload
internet
View
103
Download
0
Embed Size (px)
Citation preview
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