A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

C URSO P ROFISSIONAL T ÉCNICO DE G ESTÃO E P ROGRAMAÇÃO DE S ISTEMAS I NFORMÁTICOS P ROGRAMAÇÃO E S ISTEMAS DE I NFORMAÇÃO 11 º ANO Módulo 12 – Introdução.

Apresentações semelhantes


Apresentação em tema: "C URSO P ROFISSIONAL T ÉCNICO DE G ESTÃO E P ROGRAMAÇÃO DE S ISTEMAS I NFORMÁTICOS P ROGRAMAÇÃO E S ISTEMAS DE I NFORMAÇÃO 11 º ANO Módulo 12 – Introdução."— Transcrição da apresentação:

1 C URSO P ROFISSIONAL T ÉCNICO DE G ESTÃO E P ROGRAMAÇÃO DE S ISTEMAS I NFORMÁTICOS P ROGRAMAÇÃO E S ISTEMAS DE I NFORMAÇÃO 11 º ANO Módulo 12 – Introdução aos Sistemas de Informação Diagrama de Classes Ano lectivo 2013/2014

2 N OTA H ISTÓ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.

3 U NIFIED M ODELLING L ANGUAGE (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.

4 D IAGRAMAS 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.

5 D IAGRAMA DE C LASSES – N OÇÕES B ÁSICAS Para perceber como construir um Diagrama de Classes há que dominar os seguintes conceitos: Objecto Classe Relação

6 O BJECTO - 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?

7 O BJECTO - 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.

8 O BJECTO - 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.

9 O BJECTO - 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.

10 O BJECTO - 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.

11 O BJECTO - 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”

12 C LASSE - 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.

13 C LASSE - 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.

14 C LASSE - 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.

15 C LASSE – REPRESENTAÇÃO GRÁFICA Cliente Nome Morada Número Contribuinte Nome da classe, único no diagrama Atributos, nome único dentro da classe

16 C LASSE - 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”

17 R ELAÇÃ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.

18 R ELAÇÃ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

19 R ELAÇÃO - ASSOCIAÇÃO Representam as ligações existentes entre os objectos das classes. Representação gráfica de uma associação: Cliente Nome Morada Número Contribuinte Factura Data Valor Número Factura Facturação Cliente *

20 R ELAÇÃO – CLASSIFICAÇÃO DE ASSOCIAÇÕES Um para muitos Departamento Sigla Designação Funcionário Nome Morada Trabalha *

21 R ELAÇÃO – CLASSIFICAÇÃO DE ASSOCIAÇÕES Muitos para muitos Associação Sigla Designação Morada Associado Número Sócio Nome Data Admissão Sócio 0..*

22 R ELAÇÃO – CLASSIFICAÇÃO DE ASSOCIAÇÕES Um para um Encomenda Número Encomenda Data Valor Data Entrega Factura Número Factura Data Valor Factura Encomenda

23 R ELAÇÃ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.

24 R ELAÇÃO – CLASSES ASSOCIATIVAS No diagrama apresentado não é possível representar a quantidade de produtos encomendados. Encomenda Número Encomenda Data Valor Data Entrega Produto Código Designação Preço Produtos encomendados 0..*

25 R ELAÇÃ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.

26 R ELAÇÃ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 Encomenda Data Valor Data Entrega Produto Código Designação Preço 0..* Produtos encomendados Quantidade

27 R ELAÇÃO – A SSOC. 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úmero Nome Função Sup. Herárquico 0..* 0..1 Subordinado Chefia

28 B IBLIOGRAFIA Desenhar Bases de Dados com UML (1ª edição), da editora Edições Sílabo, da autoria de Pedro Nogueira Ramos, 2006


Carregar ppt "C URSO P ROFISSIONAL T ÉCNICO DE G ESTÃO E P ROGRAMAÇÃO DE S ISTEMAS I NFORMÁTICOS P ROGRAMAÇÃO E S ISTEMAS DE I NFORMAÇÃO 11 º ANO Módulo 12 – Introdução."

Apresentações semelhantes


Anúncios Google