Aula 13-14-15 Diagrama de Classes

Post on 24-Jul-2015

123 views 3 download

Transcript of Aula 13-14-15 Diagrama de Classes

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

1

Professor: Esp. Marcos Morais de Sousa

Curso: Sistemas de informação

Disciplina: Análise e Modelagem de Sistemas I

Identificação de classes

Turma: 04 SEMESTRE

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

2

Livros

Já falamos...

• Modelagem Aplicadas a Objetos • UML: Definição, Contexto Histórico e Visão geral • Diagrama de Caso de Uso • Exercícios sobre diagramas de Caso de Uso • Diagrama de Atividades • Exercícios sobre diagramas de Atividades • Identificação de caso de uso • Documentação • Falamos sobre o trabalho de grupo da I Unidade

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

4

Diagrama de Classes

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

5

Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com

O diagrama de classes

• O diagrama de classes representa a estrutura do sistema, recorrendo ao conceito de classe e suas relações.

• O modelo de classes resulta de um processo de abstração onde são identificados os objetos relevantes do sistema em estudo.

• Um objeto é uma ocorrência que tem interesse para o sistema em estudo e que se pretende descrever no seu ambiente, contendo identidade e comportamento.

• O comportamento de um objeto define o modo como ele age e reage a estímulos externos e a identidade de um objeto é um atributo que o distingue de todos os demais, sendo preservada quando o seu estado muda. Um objeto não é mais do que uma instância da classe.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

6

Os objetos de modelação contemplados por este diagrama são:

• Classe: é a representação de um conjunto de objetos que partilham os mesmos atributos e comportamentos;

• Relação: representa a ligação entre classes.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

7

A simbologia usada para representar estes dois conceitos é:

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

8

CLASSE

RELAÇÃO

• Cada classe é descrita através do seu nome, identificação de todos os seus atributos e identificação de todas as operações que traduzem o seu comportamento.

• O símbolo utilizado para representar a classe, e como se representa na figura a seguir, contempla três áreas distintas, uma área para se identificar o nome da classe, outra para listar os atributos e, finalmente, a terceira, para listar as operações ou métodos, também designados, segundo alguns autores, por serviços.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

9

Simbologia usada para representar uma classe

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

10

Nome da Classe

Atributos

Métodos

REGRAS DE CONSTRUÇÃO

• COMO UTILIZAR OS OBJECTOS

• O diagrama de classes mostra como cada classe se relaciona com as outras, tendo como objetivo, a satisfação dos requisitos funcionais definidos para o sistema em estudo. Neste diagrama, uma classe só pode aparecer uma vez.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

11

REGRAS DE CONSTRUÇÃO

• COMO ATRIBUIR NOMES AOS OBJETOS • Qualquer classe e relação devem ter um nome

elucidativo e claro para que o diagrama seja facilmente entendido. As classes devem ser identificadas por um nome comum, como, por exemplo, Encomenda, Produto, Cliente, etc. Os nomes das relações devem ser traduzidas através de um verbo, como, por exemplo, efectua, contém, refere, etc. Qualquer um destes nomes deve fazer parte do vocabulário do domínio do problema em estudo.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

12

COMO LIGAR OS OBJETOS

• Depois de se terem identificado as classes e os seus atributos, há que identificar as relações que existem entre as diferentes classes, de forma a satisfazer os requisitos funcionais do sistema.

• A representação da ligação entre classes faz-se recorrendo a uma linha reta, como pode ser visto na figura do próximo slide. O símbolo com a forma de um retângulo com um canto dobrado que aparece no diagrama da figura próximo slide é o utilizado para ilustrar notas ou restrições.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

13

Notação usada no diagrama de classes

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

14

• Na figura anterior, mostra-se como se representam as relações e chama-se a atenção para onde se coloca o nome e os atributos da classe. Nesta ilustração, foram identificadas duas classes, Encomenda e Produto, cada uma das quais com os seus atributos, e foi identificada a relação “Contém” entre as duas classes.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

15

• A associação acontece quando uma classe se associa a uma ou mais classes, ou mesmo com ela própria. As classes estão associadas se:

1. Um objeto de uma classe envia uma mensagem a

um objeto de outra classe;

2. Um objeto de uma classe cria um objeto de uma outra classe;

3. Um objeto de uma classe recebe uma mensagem com um objeto de outra classe como argumento.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

16

• Existem outros tipos de relações, generalização e agregação, que são casos particulares da associação.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

17

• A generalização é a relação que se estabelece entre uma superclasse e uma subclasse.

• A Classe A é uma generalização da Classe B quando A e B estão relacionados por uma relação: “B é como A”. É uma relação num sentido; se A é uma generalização de B, então B não pode ser uma generalização de A.

• A classe A é a classe pai ou superclasse e B é a classe filho ou subclasse.

• É uma associação entre classes todo-parte, conhecida como uma relação “consiste em”. Este conceito é equivalente ao conceito de herança da programação orientada a objetos, onde as subclasses, filhos, herdam da superclasse, pai, os atributos e métodos comuns.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

18

• A agregação usa-se para mostrar o fato de um todo ser composto por partes.

• Uma forma especial de agregação é a composição, que se usa quando as partes, para a sua existência, dependem da existência do todo.

• Por exemplo, não faz sentido ter uma linha de encomenda se não estiver associada a uma encomenda.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

19

Importante

• A UML reconhece três tipos mais importantes de relações: dependência, associação e generalização (ou herança).

• Geralmente as classes não estão sós e se relacionam entre si. O relacionamento e a comunicação entre as classes definem responsabilidades , temos 3 tipos : 1. Associações : Agregação e composição

2. Generalização (herança)

3. Dependências

Prof. Esp. Marcos Morais de Sousa

E-mail: marcosmoraisdesousa@gmail.com 20

As representações usam a seguinte notação :

• Associação : São relacionamentos estruturais entre instâncias e especificam que objetos de uma classe estão ligados a objetos de outras classes. Podemos ter associação uniária , binária , etc. A associação pode existir entre classes ou entre objetos. Uma associação entre a classe Professor e a classe disciplina (um professor ministra uma disciplina) significa que uma instância de Professor (um professor específico) vai ter uma associação com uma instância de Disciplina. Esta relação significa que as instâncias das classes são conectadas, seja fisicamente ou conceitualmente.[Nicolas Anquetil]

• Dependência - São relacionamentos de utilização no qual uma mudança na especificação de um elemento pode alterar a especificação do elemento dependente. A dependência entre classes indica que os objetos de uma classe usam serviços dos objetos de outra classe.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

21

• Generalização (herança : simples ou composta) - Relacionamento entre um elemento mais geral e um mais específico. Onde o elemento mais específico herda as propriedades e métodos do elemento mais geral. A relação de generalização também é conhecida como herança no modelo a objetos. Como a relação de dependência, ela existe só entre as classes. Um objeto particular não é um caso geral de um outro objeto, só conceitos (classes no modelo a objetos) são generalização de outros conceitos.

• Agregação Regular - tipo de associação ( é parte de , todo/parte) onde o objeto parte é um atributo do todo ; onde os objetos partes somente são criados se o todo ao qual estão agregados seja criado. Pedidos é composto por itens de pedidos.

• Composição - Relacionamento entre um elemento ( o todo) e outros elementos (as partes) onde as parte só podem pertencer ao todo e são criadas e destruídas com ele.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

22

Exemplos destes tipos de relações são mostrados na figura

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

23

Exemplos destes tipos de relações são mostrados na figura

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

24

Exemplos destes tipos de relações são mostrados na figura

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

25

• Num diagrama de classes, e após ter-se identificado a associação entre classes, é necessário identificar a cardinalidade de uma associação, vulgarmente designada por multiplicidade.

• A multiplicidade é especificada no extremo da associação e sobre a linha que representa a associação.

• A tabela 7.11 identifica e descreve a notação usada para representar os diferentes tipos de multiplicidade.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

26

• Quando há necessidade de se saber mais sobre a associação que se estabelece entre duas classes, surge o que se denomina por classes associativas.

• Por exemplo, se um produto pode ser comercializado por diferentes fornecedores e cada fornecedor tem um preço diferente para cada produto que comercializa, há necessidade de ter a classe Produto_Fornecedor, pois pretende-se saber qual o preço para um fornecedor específico.

• Esta classe associativa só existe devido à relação que se estabelece entre duas classes com multiplicidade de muitos para muitos e tem sempre atributos próprios.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

27

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

28

A figura mostra como se representa uma classe associativa

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

29

Fornecedor

Código Fornecedor

Produto

Código Produto

Produto Fornecedor

Preço Venda Prazo Entrega

Exemplo de uma classe associativa

ANÁLISE DE UM DIAGRAMA DE CLASSES

• No sistema de recepção de encomendas em estudo, pode-se identificar as seguintes classes: Cliente, Encomenda e Produto.

• Na figura a seguir, apresenta-se a primeira versão do diagrama de classes para o referido sistema.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

30

Primeira versão do diagrama de classes para o sistema de recepção de

encomendas

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

31

• Verifica-se que, neste sistema, a encomenda pode ser ou não satisfeita.

• Neste caso, identifica-se um caso especial, designado, no diagrama de classes, por generalização, que permite demonstrar a noção de superclasse e subclasse, herdando esta os atributos da superclasse.

• Neste mesmo sistema, nota-se a necessidade da classe Produto_Encomendado para se poder saber que produtos foram encomendados em cada encomenda; esta última classe só existe se existir a classe Encomenda.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

32

A figura representa o diagrama de classes revisto, incluindo já associações

de generalização e de composição.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

33

Diagrama de classes revisto para o sistema de recepção de encomendas

EXEMPLOS

• A melhor maneira de conceituar estes termos é considerar um objeto do mundo real e mostrar como podemos representá-lo em termos conceitos para POO.

• Começando com as definições : "Um objeto é um termo que usamos para representar uma entidade do mundo real" (Fazemos isto através de um exercício de abstração.)

• Vou usar como exemplo o meu cachorro Bilu. Posso descrever o Bilu em termos de seus atributos físicos: é pequeno , sua cor principal é castanha , olhos pretos , orelhas pequenas e caídas, rabo pequeno , patas brancas.

• Posso também descrever algumas ações que ele faz (temos aqui os métodos): balança o rabo quando chego em casa , foge e se deita se o mando sair debaixo da mesa, late quando ouve um barulho ou vê um cão ou gato, atende e corre quando o chamo pelo seu nome. Temos abaixo a representação do Bilu.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

34

O cachorro Bilu.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

35

Temos aqui a representação de um objeto , no caso o meu cachorro Bilu , que

possui as seguintes propriedades e métodos:

Propriedades : Cor do corpo : castanha cor dos olhos : preto altura: 18 cm comprimento: 38 cm largura : 24 cm Métodos : balançar o rabo , latir , deitar , sentar

O cachorro Bilu.

• Em termos de POO para poder tratar os objetos começamos criando classes , neste caso irei criar a classe chamada Cachorro.

• "Uma classe representa um conjunto de objetos que possuem

comportamentos e características comuns".

• "Na UML o nome de uma classe é um texto contendo letras e dígitos e algumas marcas de pontuação. Na realidade, é melhor guardar os nomes curtos com apenas letras e dígitos. UML sugere capitalizar todas as primeiras letras de cada palavra no nome (ex.: ``Lugar'', ``DataReserva'').

• É melhor também manter nomes de classe no singular, classes por default contém'' mais de um objeto, o plural é implícito.". [Nicolas Anquetil]

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

36

• Uma classe descreve como certos tipos de objetos se parecem do ponto de vista da programação , pois quando definimos uma classe precisamos definir duas coisas:

• Propriedades - Informações específicas relacionadas a uma classe de objeto. São as características dos objetos que as classes representam. Ex Cor , altura , tamanho , largura , etc...

• Métodos: São ações que os objetos de uma classe podem realizar. Ex: Latir , correr , sentar , comer, etc.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

37

• Você pode pensar em uma classe com um modelo para criar quantos objetos você desejar de um tipo particular.

• Pense em um carimbo com a imagem de um cachorro , quando você carimba e obtêm um desenho de cachorro você acabou de criar uma instância da classe e obteve um objeto daquela classe.

• O novo objeto possuirá todas as características e comportamentos definidos pela classe.

• (As classes especificam a estrutura e o comportamento (operações) dos objetos, que são instâncias das classes)

Prof. Esp. Marcos Morais de Sousa

E-mail: marcosmoraisdesousa@gmail.com 38

Aqui temos que Bilu é um objeto da classe Cachorro. Em termos de POO acabamos de criar uma instância da classe Cachorro e a chamamos Bilu.Quando criamos uma nova instância de uma classe dizemos que estamos instanciando a classe.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

39

• Geralmente em um sistema de médio porte serão identificados diversas classes que compõem o sistema.

• Neste contexto a UML surgiu como uma proposta de ser uma linguagem para modelagem de dados que usava diversos artefatos para representar o modelo de negócio ; um destes artefatos é o diagrama de classes.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

40

A representação de uma classe usa um retângulo dividido em três partes:

• nome

• atributos

• métodos

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

41

Lembre-se

• Podemos dizer que os diagramas de classes são os principais diagramas estruturais da UML pois ilustram as classes , interfaces e relacionamentos entre elas.

• Os diagrama se classes ilustram atributos e operações de uma classe e as restrições como que os objetos podem ser conectados ; descrevem também os tipos de objetos no sistema e os relacionamentos entre estes objetos que podem ser : associações e abstrações.

• Para poder representar a visibilidade dos atributos e operações em uma classe utiliza-se as seguintes marcas e significados: 1. + público - visível em qualquer classe 2. # protegido - qualquer descendente pode usar 3. - privado - visível somente dentro da classe

Prof. Esp. Marcos Morais de Sousa

E-mail: marcosmoraisdesousa@gmail.com 42

conceitos do domínio

• O diagrama de classes lista todos os conceitos do domínio que serão implementados no sistema e as relações entre os conceitos. Ele é muito importante pois define a estrutura do sistema a desenvolver.

• O diagrama de classes não surge do nada ele é consequência do prévio levantamento de requisitos , definição de casos de usos e classes. Como exemplo vamos supor que você tivesse que desenvolver um sistema para automatizar um consultório dentário. As etapas básicas envolvidas seriam: – Levantamento e análise de requisitos do sistema a ser desenvolvido. Entrevista com o

dentista(s) e com as pessoas que trabalham no consultório – Definição dos objetos do sistema : Paciente , agenda , dentista , serviço , contrato , consulta

, pagamento , etc.. – Definição dos atores do sistema : paciente, dentista , secretária – Definição e detalhamento dos casos de uso: marcar consulta , confirmar consulta , cadastrar

paciente , cadastrar serviços , etc. – Definição das classes : paciente , dentista , exame , agenda , serviço – Definir os atributos e métodos das classes :

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

43

Após toda esta análise você chega no diagrama de classes do sistema (representado abaixo a título de exemplo ilustrativo)

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

44

Atributo

• Um atributo representa uma propriedade que todos os objetos da classe têm (por exemplo, todos os cachorros tem pelo , orelhas , altura, ,etc. Mas cada objeto terá valores particulares para seus atributos (alguns cachorros são mais baixos , outros são maiores, etc.).

• Uma classe pode ter qualquer número de atributos. Na UML, o nome de um atributo é um texto contendo letras e dígitos e algumas marcas de pontuação. UML sugere de capitalizar todas as primeiras letras de cada palavra no nome menos a primeira palavra (ex.: "nome'', "nomeCachorro'').

• Num modelo, os atributos devem ser de um tipo simples (inteiro, texto, talvez data), não podem conter outros objetos.

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

45

Métodos

• Métodos são ações que implementam uma operação. Uma classe pode ter qualquer número de métodos e dois métodos em duas classes podem ter o mesmo nome.

• Todos os métodos que vão implementar a operação tem que respeitar exatamente a assinatura dela (mesmo nome, mesmo número de atributo, com os mesmo tipos e o mesmo ordem). Um método não pode acrescentar ou cortar um parâmetro. Isso seria um violação do polimorfismo. Para mandar a mensagem corretamente, teríamos que saber qual é a classe do objeto (cada classe tendo método com assinatura diferente). O que é possível, no caso de cortar um parâmetro, é simplesmente ignorá-lo na implementação. [Nicolas Anquetil]

Prof. Esp. Marcos Morais de Sousa E-mail: marcosmoraisdesousa@gmail.com

46