Prof. Thales Castro

 Breve revisão  Diagramas de Classe

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

 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

 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

 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

 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

 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

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

 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

 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

 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

 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

 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;

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

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

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

 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

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

 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

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

 Exemplo de um modelo de domínio Recebe Atende

 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

 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

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

 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

 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

 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

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

 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

 Componentes Classes Relacionamentos Anotações

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

 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)

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

 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

 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

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

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

 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

 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.

Recebe Atende

 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;

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

 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

 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

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

 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

 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.

 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

 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)

 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

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.

 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

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

 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

 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

Classe Pai Classes Filhas Forma de Representação

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

 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

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

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

 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

Stereotypes

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

Stereotypes

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

 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

 Anotações

 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

Prof. Thales Castro