UML. Diagrama de Classe

Documentos relacionados
15/04/2013. Outro Diagrama de Classes. Primeiro Diagrama de Classes. Diagrama de Classes. Atributos. Eduardo Figueiredo

Diagramas de Classes. ESII Profª. Andressa Falcade URI Santiago

UML LINGUAGEM DE MODELAGEM UNIFICADA Diagrama de Classes

BANCO DE DADOS I. Prof. Luiz Antônio Vivacqua C. Meyer

Linguagem de Programação. Diagrama de classes

UML Diagrama de Classes

Análise Orientada a Objetos. Análise Orientada a Objetos; O Paradigma de Objetos; A UML.

Diagrama de Classes. Régis Patrick Silva Simão. Régis Simão Diagrama de Classes 1/42

Diagrama de Classes. Classes. Relacionamentos. Atributos Métodos. Associação. Generalização Dependência Realização. Agregação Composição

Introdução à UML. Prof. Jesus José de Oliveira Neto

Programação para Games II. Professor Ariel da Silva Dias Orientação a Objetos

Orientação a Objetos (OO)

Modelagem Orientada a Objeto

Modelagem de Processos

Panorama da notação UML

12/03/16. Generalização. Associação. Agregação UML Relações. entre Classes. Composição. Prof.Dr. Enzo Seraphim. Dependência

Análise e projeto de sistemas

Análise de Sistemas 4º Bimestre (material 3)

Engenharia de Software. Aula 10 Representação dos Conceitos de Orientação a Objetos. Prof. Me. Rogério Ferreira

Linguagem de Modelagem Unificada UML

Engenharia de Software II e III - Material para estudo Diagrama de Classe

PROJETO DE BANCO DE DADOS -PROJETO CONCEITUAL. Prof. Angelo Augusto Frozza, M.Sc.

Modelo Conceitual. Análise e Projeto de Sistemas Avançados. Aula 5. Allan Rodrigo Leite

Programação Orientada a Objetos 2 Flávio de Oliveira Silva, M.Sc.

Engenharia de Software II e III - Introdução ao Diagrama de Classe

Programação Orientada a Objetos Relacionamentos entre classes

Modelagem de dados usando o modelo Entidade- Relacionamento (ER)

UML. Diagrama de Classes

PROGRAMAÇÃO ORIENTADA A

MAPEAMENTO OBJETO RELACIONAL. Professora Lucélia Oliveira

MODELAGEM VISUAL DE OBJETOS COM UML DIAGRAMA DE CLASSES.

Tópicos da Aula. Diretrizes Gerais. Trabalho Prático (TP) Pontuação do TP. Tema do Trabalho. Projeto de Software Diagrama de Classes

Programação Orientada a Objetos

Revisão Diagrama de classes Elementos do diagrama de classes Exemplo: Sistema de matrícula

UML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos

Capítulo 5 Modelação do Sistema 1

FUNDAÇÃO UNIVERSIDADE ESTADUAL DE MARINGÁ

Classes e Objetos. Sintaxe de classe em Java

Unified Modeling Language (UML)

DIAGRAMAS DE CLASSE UML

UML Relacionamentos. Relacionamento é uma conexão entre itens A maioria dos itens relacionam-se entre si. Quatro tipos de relacionamentos:

Conceitos de Programação Orientada a Objetos

Unidade 2 Modelo Conceitual

Modelagem de Classes. Mestrado em Engenharia de Produção e Sistemas Computacionais. Profa. Adriana Pereira de Medeiros

Modelos. Banco de dados. Professor: Jarbas Araújo CENTRO EDUCACIONAL RADIER.

Programação Orientada a Objetos

MODELAGEM DE SISTEMAS. Introdução a Computação e Engenharia de Software. Profa. Cynthia Pinheiro

Modelagem semântica permite aproximar o modelo obtido do mundo real Exemplo de modelos:

Unidade 3 23/10/2008. Curso Superior de Tecnologia: Banco de Dados Sistemas para Internet Redes de Computadores

Modelagem Usando Orientação à Objetos (Programação Orientada a Objetos) Prof. Responsáveis Wagner Santos C. de Jesus

Programação Orientada a Objetos

Extensões do Modelo Entidade-Relacionamento

SISTEMA DE INFORMAÇÃO Modelo Conceitual. Prof. Luiz Fernando Laguardia Campos FMS

Linguagem de Programação II Herança

Modelagem Conceitual parte I

Modelagem Conceitual parte I

Introdução Diagrama de Classes Diagrama de Seqüência Diagrama de Atividades. Diagramas UML. Classe, Seqüência e Atividades. Marcio E. F.

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Análise e Projeto de Sistemas

Modelagem de Dados Usando o Modelo Entidade-Relacionamento (ME-R)

Banco de Dados Modelagem Conceitual de Dados. Prof. Edjandir Corrêa Costa

Análise e Projeto de Sistemas I

PROGRAMAÇÃO ORIENTADA A OBJETOS I -TÉCNICAS DE OO. Prof. Angelo Augusto Frozza, M.Sc.

POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos

Herança - Conceitos Básicos

Orientação a Objetos (OO) LPG II - Java. Orientação a Objetos (OO) Programação Orientada a Objetos. Programação Procedimental

Diagramas de Classes. Diagramas de Classes. Diagramas de Classes. Análise e Projeto de Sistemas OO

AULA 02. OBJETIVO: Características da Linguagem Orientada a Objetos.

Introdução à Orientação a Objetos

Projeto Banco de Dados

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 15 PROFª BRUNO CALEGARO

Modelagem de Casos de Uso. Sistemas de Informação

Análise e projeto de sistemas

Herança - Conceitos Básicos

Diagramas de Use Case Resumo

UML - Diagrama de Classes

Transcrição:

UML Diagrama de Classe

Em UML as classes são representadas por um retângulo dividido em três compartimentos: o compartimento de nome, que conterá apenas o nome da classe modelada, o de atributos, que possuirá a relação de atributos que a classe possui em sua estrutura interna, e o compartimento de operações, que serão o métodos de manipulação de dados e de comunicação de uma classe com outras do sistema.

A sintaxe usada em cada um destes compartimentos é independente de qualquer linguagem de programação.

Exemplo de Classe

Como sugestão, o nome da classe deveria utilizar apenas letras e palavras concatenadas mantendo-se a primeira letra de cada palavra em maiúscula. Exemplo: Cliente TurmaEspecial

Notação para definição de atributos: [Visibilidade] Nome-Atributo Multiplicidade]:[Tipo]=[Valor] [{Propriedades}] Visibilidade: A visibilidade indica se o atributo pode ou não ser acessado do exterior da classe por funções que não sejam membro da classe.

Existem 3 especificadores de visibilidade : + : indica visibilidade pública. Neste caso o atributo é visível no exterior da classe. Tanto funções membro da classe quanto funções externas podem acessar o atributo. - : indica visibilidade privada. Neste caso o atributo não é visível no exterior da classe. Somente funções membro da classe podem acessar o atributo. # : indica visibilidade protegida. Neste caso o atributo também é privado mas funções membro de classes derivadas também tem acesso ao atributo. A definição da visibilidade do atributo é opcional. Entretanto, se ela não for especificada, assume-se por padrão visibilidade privada.

Atributo Sugere-se o emprego unicamente de letras começando-se por uma letra minúscula e concatenando-se palavras mantendo a primeira letra em maiúsculo. Exemplo: valorpagamento cliente nomealuno

Notação para a definição de métodos: [Visibilidade] Nome-Método (Parâmetros):[Valor-de-Retorno] [{Propriedades}] A visibilidade indica se o método pode ou não ser chamado do exterior da classe por funções que não sejam membro da classe. Existem três especificadores de visibilidade:

+ indica visibilidade pública. Neste caso o método é visível no exterior da classe. Tanto funções membro da classe quanto funções externas podem acessar ao método. - indica visibilidade privada. Neste caso o método não é visível no exterior da classe. Somente funções membro da classe podem acessar ao método. # indica visibilidade protegida. Neste caso o método também é privado mas funções membro de classes derivadas também tem acesso ao método. A definição da visibilidade do método é opcional. Entretanto, se ela não for especificada, assume-se por padrão visibilidade privada.

O nome do método é definido por uma cadeia de caracteres que identificam exclusivamente o método dentro da classe. Sugere-se o emprego unicamente de letras começando-se por uma letra maiúscula e concatenando-se palavras mantendo a primeira letra em maiúsculo. Exemplo: CalcularValor, ArmazenarDados

Os parâmetros são variáveis definidas junto aos métodos e que são utilizadas pelos métodos para recebimento de valores no momento da ativação. Os parâmetros podem também ser utilizados para retorno de valores após a execução do método. Exemplo: CalcularValor(val1:int, val2:float=10.0)

O Valor-de-Retorno indica se o método retorna algum valor ao término de sua execução e qual o tipo de dado do valor retornado. Pode-se utilizar aqui os tipos padrões da linguagem de programação que se pretende utilizar ou novos tipos definidos no projeto (inclusive classes).

Exemplo: CalcularValor():int // retorna um valor inteiro ArmazenarDados(nome:char[30]): boolean // retorna verdadeiro ou falso

Levantamento das classes A definição das classes necessárias para a realização de todas as funcionalidades do sistema envolve um processo de síntese, ou seja, de criação. Não existe um algoritmo ou técnica precisa para o estabelecimento de classes. Cabe ao projetista, baseado em sua experiência e criatividade determinar quais classes irão compor o sistema. A definição das classes exige um estudo detalhado dos requisitos do sistema e das possibilidades de separação dos dados e processos em classes.

Relacionamento entre Classes Existem, basicamente, 3 tipos de relacionamentos entre classes: associação, agregação e generalização.

Associação A associação é o tipo de relacionamento mais comum e mais importante em um sistema orientado a objetos. Praticamente todo sistema orientado a objetos terá uma ou mais associações entre suas classes. Uma associação é um relacionamento ou ligação entre duas classes permitindo que objetos de uma classe possam comunicar-se com objetos de outra classe.

Notação UML para associações: Nome e sentido: A notação UML para uma associação é um segmento de reta ligando as duas classes. Se a associação for unidirecional, inclui-se uma seta na extremidade de destino da associação. Opcionalmente, mas fortemente sugerido, podese incluir um nome na associação. Este nome é colocado sobre o segmento de reta e tem como propósito indicar a natureza da associação.

A associação Registra é unidirecional indicando que objetos da classe Secretaria podem se comunicar com objetos da classe Aluno. Observe que neste caso, a associação não pode ser navegada no sentido contrário, ou seja, objetos da classe Aluno não podem se comunicar com objetos da classe Secretaria.

Papéis das Classes Pode-se, ainda, incluir uma indicação dos papéis das classes nas associações. Uma especificação de papel indica qual a participação ou atribuição de cada classe na associação. A indicação de papel é feita colocando-se a especificação do papel na forma de um texto nos extremos da associação de forma a indicar, para cada classe, qual o seu papel. Não é comum indicar o nome da associação e os papéis das classes para uma mesma associação. Normalmente, opta-se por uma ou outra especificação.

Cardinalidade A cardinalidade é uma indicação que especifica o número de objetos de cada classe envolvidos com a associação. Quando não há uma especificação de cardinalidade, entende-se que a cardinalidade é 1. Isto significa que apenas um objeto de cada classe esta envolvido com a associação. A especificação de cardinalidade é feita em cada extremo da associação e utiliza-se a seguinte notação :

Deve-se fazer a leitura da cardinalidade de forma distinta para os dois sentidos da associação. Para cada um dos sentidos deve-se esquecer a cardinalidade no extremo de inıcio da leitura e considerar que existe uma associação de UM objeto da classe de início da leitura com tantos objetos quanto estiver especificado pela cardinalidade da classe na outra extremidade da associação. Para o exemplo dado na figura anterior deve-se fazer a seguinte leitura: Um objeto da classe Cturma se associa com 40 objetos da classe CAluno, e um objeto da classe CAluno se associa com um número indefinido (inclusive zero) de objetos da classe Cturma.

Agregação Agregação é uma forma especializada de associação na qual o todo está relacionado a sua(s) parte(s). Agregação é conhecida como parte-de ou relacionamento de conteúdo. Uma agregação é representada como uma associação com um losango perto da classe que denota a agregação (todo). A multiplicidade é representada da mesma maneira que nas outras associações.

Testes de Agregação A frase parte de é usada para descrever o relacionamento? Uma Porta é parte de um Carro Algumas operações no todo são automaticamente aplicadas nas partes? Mova o Carro, Mova a Porta Alguns valores de atributos são propagados do todo para algumas ou todas as suas partes? O Carro é azul, a Porta é azul Há uma assimetria intrínseca no relacionamento onde uma classe é subordinada a outra? Uma Porta É parte de um Carro, um Carro NÃO É parte de uma Porta

Tipos de Agregação Existem dois tipos de agregação: Agregação propriamente dita, ou também chamada agregação por referência Conhecida como relacionamento tem-um(a) Envolve partes componentes que existem independentemente de seus agregados Exemplo: A área X da empresa tem os empregados A, B e C. Visualizando o conceito de agregação, o agregado contém uma referência aos seus componentes.

Composição, ou também chamada agregação por valor Conhecida como relacionamento contém um(a) Especifica que as partes componentes só tem um dono Especifica que o composto possui suas partes componentes Especifica que as partes componentes existem, ou vivem e morrem com seu composto proprietário Exemplo: Um automóvel possui de 2 a 5 portas. Visualizando o conceito de composição, o composto contém os seus componentes

Associação ou Agregação? Se dois objetos são estreitamente ligados por um relacionamento parte-todo, o relacionamento é uma agregação. Se dois objetos são usualmente considerados independentes, mesmo que eles estejam frequentemente ligados, o relacionamento é uma associação.

Encontrando Associações e Agregações

Generalização Generalização define um relacionamento entre classes onde uma classe compartilha a estrutura e/ou comportamento de uma ou mais classes. Generalização define uma hierarquia de abstrações na qual uma subclasse herda de uma ou mais superclasses. Com herança simples, a subclasse herda de apenas uma superclasse. Com herança múltipla, a subclasse herda de mais de uma superclasse. Generalização é um relacionamento "é um" ou "tipo de.

Relacionamento de herança (generalização)

Considerações sobre generalização Como um relacionamento de generalização não se refere a objetos individuais: O relacionamento não é nomeado Multiplicidade não tem sentido Teoricamente, não há limite no número de níveis em uma hierarquia.

O que é Herdado? Uma subclasse herda de seus pais: Atributos Operações Relacionamentos Uma subclasse pode: Incluir atributos, operações e relacionamentos adicionais.

Exemplo de Generalização

Herança Múltipla

Conceitos de Herança múltipla Conceitualmente é necessário para modelar o mundo real de forma precisa. Na prática, isto pode gerar dificuldades na implementação. Nem todas as linguagens de programação orientadas a objetos suportam herança múltipla diretamente. Cada ambiente/linguagem de programação escolhe maneiras de resolver estas dificuldades.

Encontrando Generalização É importante avaliar todas as classes para encontrar possíveis generalizações. Procure por comportamento comum (operações) e estado comum (atributos) nas classes. Técnica de adição Adicione novas operações/atributos na(s) subclasse(s) Técnica de modificação Redefina operações Deve ser feito com cuidado para não alterar a semântica

Generalização x Agregação Generalização e agregação são geralmente confundidas. Generalização representa um relacionamento "é-um" ou "tipo-de. Agregação representa um relacionamento "tem-um.

Exercícios