Prof. Thales Castro.  Breve revisão  Diagramas de Classe.

Apresentação em tema: "Prof. Thales Castro.  Breve revisão  Diagramas de Classe."— Transcrição da apresentação:

1 Prof. Thales Castro

2  Breve revisão  Diagramas de Classe

3  Composto por 9 Diagramas  Cada diagrama composto por uma série de itens  Itens dos diagramas relacionados através de conectores

4  Diagrama de Caso de Uso  Diagrama de Classes  Diagrama de Objetos  Diagrama de Pacotes  Diagrama de Estado  Diagrama de Sequencia  Diagrama de Colaboração  Diagrama de Atividade  Diagrama de Componente  Diagrama de Implantação

5

6  Diagrama de Caso de Uso  Diagrama de Classes  Diagrama de Objetos  Diagrama de Pacotes  Diagrama de Estado  Diagrama de Sequencia  Diagrama de Colaboração  Diagrama de Atividade  Diagrama de Componente  Diagrama de Implantação

7  Descreve entidades do mundo real ◦ Enfatiza os dados que serão necessários para a construção do sistema, em vez de funcionalidades  Dentre todos, é o que possui maior quantidade de símbolos para notação  Não é novo: evolução do antigo DER

8  Ideia central: ◦ Concentrar a construção do sistema em torno dos objetos (mais próximo do mundo real)  No diagrama de classes, o analista precisa: ◦ Identificar essas entidades em um conjunto de objetos ◦ Identificar como esse conjunto de objetos interagem entre si

9  Identificando os objetos: ◦ Os objetos são identificados conforme entidades que existem em um determinado domínio  Iteração: ◦ Por meio de troca de mensagens  Requisição de um serviço; ou  Reação a uma outra mensagem

10  Esse mapeamento torna um problema mais fácil de ser entendido: ENTIDADES (CLASSES)

11  Deve-se obter apenas aqueles que são importantes no contexto  Uma entidade, então, vai representar um conjunto de objetos que possuem determinadas características em comum;  No exemplo, podemos identificar as classes: ◦ Garçom ◦ Prato ◦ Cliente

12  Logo, principais objetivos do Diagrama de Classes: ◦ Permitir a visualização dos conceitos, que por sua vez serão disponibilizados em base de dados ◦ Atender às demandas geradas pelos casos de uso e seus atores

13  Este modelo de objetos representa o aspecto estrutural e estático dos objetos do sistema  Dois diagramas são utilizados na construção do modelo de objetos: ◦ Diagrama de Classes ◦ Diagrama de Objetos

14  Na prática, o diagrama de classes é bem mais utilizado que o de objetos ◦ Tanto que o diagrama de objetos é mais conhecido como diagrama de classes  Esse modelo evolui durante o desenvolvimento do sistema ◦ Incremento de novos detalhes aos Diagrama de Classes

15  Essas classes sempre possuem: ◦ Atributos (informações da entidade/classe) ◦ Métodos (ações que podem ser realizadas pelos objetos)  No exemplo: ◦ Garçom  Atributos: Matricula, Nome, Telefone, Comissão;  Métodos: Servir uma mesa para um cliente; ◦ Prato  Atributos: Nome, Valor, Ingredientes;  Métodos: finalizar preparação;

16  Como representar as classes? Nome da classe Atributos da classe Métodos da classe

17  Deve possuir ◦ Classes existentes no sistema ◦ Relacionamento entre as classes

18  Existem 3 perspectivas do Diagrama de Classes: ◦ Conceitual ou de Domínio ◦ Especificação ◦ Implementação

19  Representa os conceitos do domínio da aplicação  Geralmente destinadas ao cliente  Considerado independente da linguagem de programação  Construído na fase de análise  Pouco ou nenhum enfoque a software

20  Processo de criação: ◦ Passo 1: identificação dos conceitos do sistema ◦ Passo 2: identificação das associações entre as classes

21  Passo 1: identificação dos conceitos  Investigação de relatórios, documentos, textos  Entrevistas com usuários  Identificação de outros softwares relacionados  Qualquer artefato que leve à conhecimento do domínio do problema

22  Para criar o modelo de domínio, crie uma lista com as classes  Ex.: Garçom Prato Cliente

23  Exemplo de um modelo de domínio Recebe Atende

24  Lendo o Modelo de Domínio: ◦ Um instância de garçom recebe os pratos (outra instância) ◦ Essa mesma instância de garçom atende aos clientes

25  Diretrizes Importantes: ◦ Criar nomes sempre no singular ◦ Usar um nome que identifique o conceito, e não a sua coleção ◦ Usar nomes que identifiquem facilmente o relacionamento

26  Existem 3 perspectivas do Diagrama de Classes: ◦ Conceitual ou de Domínio ◦ Especificação ◦ Implementação

27  Características: ◦ Destinado a pessoas que não necessitam dos detalhes do desenvolvimento  Ex.: gerentes de projeto, analista de dados ◦ Neste nível, novas classes podem ser definidas para a solução do problema ◦ Define a navegabilidade entre as classes

28  Características: ◦ Foca nas principais interfaces do modelo ◦ Mostra os métodos, mas não sua implementação ◦ Define a navegabilidade entre as classes ◦ Diagrama definido na fase de projeto

29

30  Diretrizes Importantes: ◦ Devem estar coerentes com os nomes criados no Diagrama de Domínio ◦ Podem, porém, ser criadas novas classes, a depender da necessidade

31  Existem 3 perspectivas do Diagrama de Classes: ◦ Conceitual ou de Domínio ◦ Especificação ◦ Implementação

32  Características: ◦ Muito voltado para a equipe de desenvolvimento, por estar muito associado à implementação e ao modelo de dados da aplicação ◦ Aborda os detalhes de implementação  Navegabilidade  Atributos  Tipos dos atributos  Métodos  Dentre outros

33  Componentes Classes Relacionamentos Anotações

34  Componentes: ◦ Classes ◦ Relacionamentos ◦ Anotações

35  Classes ◦ A representação deve incluir todos os atributos e métodos da classe ◦ Deve ser identificado o nível de acesso de cada atributo e método ◦ Cada atributo e método deve possuir seus respectivos tipos (inclusive dos parâmetros)

36  A representação deve incluir todos os atributos e métodos da classe Atributos da classe Métodos da classe

37  Deve ser identificado o nível de acesso de cada atributo e método  +: representação de atributos ou métodos públicos  -: representação de atributos ou métodos privados  #: representação de atributos ou métodos protegidos

38

39  Cada atributo e método deve possuir seus respectivos tipos (inclusive dos parâmetros) ◦ void: para métodos ◦ String, int, Boolean, etc...: tipos simples utilizados pelos atributos E para retorno de funções ◦ Classe: tipos complexos também utilizados pelos atributos e para retorno de funções

40

41  Cada atributo e método deve possuir seus respectivos tipos (inclusive dos parâmetros)

42  Componentes: ◦ Classes ◦ Relacionamentos ◦ Anotações

43  Relacionamentos ◦ Indicam formas de comunicação entre as classes do sistema ◦ Algumas formas:  Associações  Generalizações e Especializações  Classes Associativas  Agregações & Composições  Classes Abstratas

44  Associações ◦ Para representar o fato de que objetos podem se relacionar uns com os outros, utilizamos associações. ◦ Uma associação representa relacionamentos (ligações) que são formados entre objetos durante a execução do sistema ◦ Note que, embora as associações sejam representadas entre classes do diagrama, tais associações representam ligações possíveis entre os objetos das classes envolvidas.

45 Recebe Atende

46  Multiplicidades ◦ Representam a informação dos limites inferior e superior da quantidade de objetos aos quais outro objeto pode se associar. ◦ Cada associação em um diagrama de classes possui duas multiplicidades, uma em cada extremo da linha de associação. NomeSimbologia UML Apenas um1 Zero ou Vários0..* Um ou Vários1..* Zero ou um0..* Quantidade específica10 (onde 10 representa a quantidade;

47 O cliente pede 0 ou vários pedidos Um pedido está associado a apenas 1 cliente Um velocista corre 0 ou várias corridas Uma corrida tem no mínimo 2 e no máximo 6 velocistas

48  Associação ◦ Participação: característica que indica a necessidade de existência da associação entre objetos ◦ Participação pode ser obrigatória ou opcional  Obrigatória: cardinalidade mínima de 1  Opcional: cardinalidade mínima de 0

49  Associação ◦ Para melhor esclarecer o significado de uma associação no diagrama de classes, a UML define três recursos de notação:  Nome da associação: fornece algum significado semântico a mesma.  Direção de leitura: indica como a associação deve ser lida  Papel: para representar um papel específico em uma associação

50 Nome da associação Papel Nome da associação

51  Classe Associativa ◦ É uma classe que está ligada a uma associação, em vez de estar ligada a outras classes. ◦ É normalmente necessária quando duas ou mais classes estão associadas, e é necessário manter informações sobre esta associação. ◦ Uma classe associativa pode estar ligada a associações de qualquer tipo de conectividade. ◦ Sinônimo: classe de associação

52  Notação é semelhante à utilizada para classes ordinárias. A diferença é que esta classe é ligada a uma associação por uma linha tracejada.  Exemplo: para cada par de objetos [pessoa, empresa], há duas informações associadas: salário e data de contratação.

53  Associações Reflexivas ◦ Tipo especial que representa ligações entre objetos que pertencem a uma mesma classe  Não indica que um objeto se associa a ele próprio

54  Agregações e Composições ◦ A semântica de uma associação corresponde ao seu significado, ou seja, à natureza conceitual da relação que existe entre os objetos que participam daquela associação. ◦ De todos os significados diferentes que uma associação pode ter, há uma categoria especial de significados, que representa relações todo-parte. ◦ Uma relação todo-parte entre dois objetos indica que um dos objetos está contido no outro. Podemos também dizer que um objeto contém o outro. ◦ Ex.:  Carro (todo) possui Motor, Bancos, Rodas, etc. (Partes)  Pedidos (todo) possuem Itens de Pedidos (Partes)  Associação Esportiva (todo) possuem Equipes (Partes), que por sua vez possuem Jogadores (parte)

55  Agregações e Composições ◦ A UML define dois tipos de relacionamentos todo- parte, a agregação e a composição. ◦ Agregação:  A existência do Objeto-Parte faz sentido, mesmo não existindo o Objeto-Todo  Representado por um Losango sem preenchimento

56 Um time é formado por atletas, ou seja, os atletas são parte integrante de um time, mas os atletas existem independentemente de um time existir. Nesse caso, chamamos esse relacionamento de AGREGAÇÃO.

57  Agregações e Composições ◦ Composição:  A existência do Objeto-Parte não faz sentido se o Objeto- Todo não existir  Representado por um Losango com preenchimento

58 Nesse caso, um pedido é composto por um ou vários itens, mas um produto NÃO é item de um pedido se não existe pedido. Assim, chamamos esse relacionamento de COMPOSIÇÃO

59  Restrições sobre Associações ◦ Ao definir o diagrama de classes, pode-se também gerar restrições nas associações, de forma a adicionar a ela mais semântica. ◦ Duas das restrições sobre associações predefinidas pela UML: xor e subset.  XOR: ou um ou outro objeto  Subset: um conjunto ou sub-conjunto

60

61  Heranças ◦ Já trabalhado em sala de aula  Generalização x Especialização ◦ Notação em UML definida pelo triângulo associado com as classes filhas

62 Classe Pai Classes Filhas Forma de Representação

63  Interface ◦ Forma de pre-informar os métodos que devem ser implementados ◦ Notação em UML definida pelo círculo

64

65  Classes abstratas ◦ Existem classes que não geram instâncias diretas.  Essas são as classes abstratas. ◦ Classes abstratas são utilizadas para organizar e simplificar uma hierarquia de generalização.  Propriedades comuns a diversas classes podem ser organizadas e definidas em uma classe abstrata a partir da qual as primeiras herdam.  Subclasses de uma classe abstrata também podem ser abstratas, mas a hierarquia deve terminar em uma ou mais classes concretas. ◦ Forma de pre-informar os métodos que devem ser implementados

66  Classes abstratas ◦ Forma de pre-informar os métodos que devem ser implementados ◦ Notação definida pelos nome em itálico

67 Classe Abstrata Implementação do método abstrato Método Abstrato

68  Esteriótipos (stereotypes) ◦ Permite “classificar” elementos com algo em comum  Ex.: modelar uma aplicação pode ser necessário informar as classes de camada de apresentação e outra de negócios ◦ Graficamente representado por um nome entre dois sinais “ >” ◦ Pode ser utilizado tanto para classes quanto para atributos e métodos ◦ Existem alguns pré-definidos para UML

69 Stereotypes

70  Enumerações ◦ Todo atributo precisa de um tipo de Dados ◦ Alguns, porém, são tipos pré-definidos  A esses chamamos enumeration

71 Stereotypes

72  Componentes: ◦ Classes ◦ Relacionamentos ◦ Anotações

73  Anotações ◦ Basicamente anotações relacionadas a alguma classe ou relacionamentos ◦ Lembretes importantes que devem ser disponibilizados para desenvolvedores ◦ Formato de textos simples ou de Notas  Textos estão associados ao diagrama  Notas estão geralmente associadas (linkadas) com Classes

74  Anotações

75  Conclusão ◦ Note que todos esses conceitos (e alguns mais) estão presentes no diagrama de classes da ferramenta ◦ Para fixar todos esses conceitos, vamos ver alguns exercícios ◦ Todas as classes criadas posteriormente podem dar vazão ao diagrama de objetos

76 Prof. Thales Castro