Post on 12-Sep-2018
1UML – Diagramas de Classes– v.1.2, João Pascoal Faria, Outubro de 2002
UML – Diagramas de Classes
2UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Índice
n Objectivo dos diagramas de classes
n Objectos, classes, atributos e operações
n Relações entre classes: associação, agregação e composição
n Relações entre classes: generalização
n Relações entre classes: dependência e concretização
n Restrições, elementos derivados, pré-condições e pós-condições
n Classes especiais: classes parametrizadas, interfaces, tipos, meta-classes e utilitários
3UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Objectivo dos diagramas de classes
n Um diagrama de classes serve para modelar o vocabulário de um sistema, do ponto de vista do utilizador/problema ou do implementador/solução
• Ponto de vista do utilizador/problema – na fase de captura e análise de requisitos, em paralelo com a identificação dos casos de utilização
• Vocabulário do implementador/solução – na fase de projecto (design)
n Construído e refinado ao longo das várias fases do desenvolvimento do software, por analistas, projectistas (designers) e implementadores
n Também serve para:• Especificar colaborações (no âmbito de um caso de utilização ou mecanismo)• Especificar esquemas lógicos de bases de dados• Especificar vistas (estrutura de dados de formulários, relatórios, etc.)
n Modelos de objectos de domínio, negócio, análise e design
4UML – Diagramas de Classes– v.1.2, João Pascoal Faria, Outubro de 2002
Objectos, classes, atributos e operações
5UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Objectosn Um objecto é algo com fronteiras bem definidas,
n relevante para o problema em causa,
n com estado,• modelado por valores de atributos (tamanho, forma, peso, etc.) e por
ligações que num dado momento tem com outros objectos
n comportamento• um objecto exibe comportamentos invocáveis (por resposta a chamadas de
operações ) ou reactivos (por resposta a eventos)
n e identidade• no espaço: é possível distinguir dois objectos mesmo que tenham o mesmo
estado- exemplo: podemos distinguir duas folhas de papel A4, mesmo que tenham os
mesmos valores dos atributos
• no tempo: é possível saber que se trata do mesmo objecto mesmo que o seu estado mude
- exemplo: se pintarmos um folha de papel A4 de amarelo, continua a ser a mesma folha de papel
6UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Objectos do mundo real e objectos computacionaisn No desenvolvimento de software orientado por objectos, procura-
se imitar no computador o mundo real visto como um conjunto de objectos que interagem entre si
n Muitos objectos computacionais são imagens de objectos do mundo real
n Dependendo do contexto (análise ou projecto) podemos estar a falar em objectos do mundo real, em objectos computacionais ou nas duas coisas em simultâneo
n Exemplos de objectos do mundo real: • o Sr. João• a aula de ES no dia 11/10/2000 às 11 horas
n Exemplos de objectos computacionais: • o registo que descreve o Sr. João (imagem de objecto do mundo real)• uma árvore de pesquisa binária (objecto puramente computacional)
7UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Classes (1)
n No desenvolvimento de software OO, não nos interessam tanto os objectos individuais mas sim as classes de objectos
n Uma classe é um descritor de um conjunto de objectos que partilham as mesmas propriedades (semântica, atributos, operações e relações)
• Trata-se de uma noção de classe em compreensão , no sentido de tipo de objecto , por oposição a uma noção de classe em extensão , como conjunto de objectos do mesmo tipo
n Um objecto de uma classe é uma instância da classe
n A extensão de uma classe é o conjunto de instâncias da classe
n Em Matemática, uma classe é um conjunto de “objectos” com uma propriedade em comum, podendo ser definida indiferentemente em compreensão ou em extensão
C = {x ∈|N : x mod 3 = 2} = {2, 5, 8, 11, 14, ...}
8UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Classes (2)
n O conjunto de todos os objectos num determinado contexto forma um universo (UoD - Universe of Discourse)
n As extensões das classes são subconjuntos desse universo
UoD x João
x Rui
x Maria
AlunoCurso
x Electrotecnia
x Informática
objecto x Dª Ritax Sr. Silva Funcionário
classe
ligação
9UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Classes (3)
n Classes podem representar:• Coisas concretas: Pessoa, Turma, Carro, Imóvel, Factura, Livro
• Papéis que coisas concretas assumem: Aluno, Professor, Piloto
• Eventos: Curso, Aula, Acidente• Tipos de dados: Data, Intervalo de Tempo, Número Complexo,
Vector
n Decomposição orientada por objectos : começa por identificar os tipos de objectos (classes) presentes num sistema
• contrapor com decomposição funcional ou algorítmica
• tipos de objectos são mais estáveis do que as funções, logo a decomposição orientada por objectos leva a arquitecturas mais estáveis
10UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Classes (4)
n Em UML, uma classe é representada por um rectângulo com o nome da classe
n Habitualmente escreve-se o nome da classe no singular (nome de uma instância), com a 1ª letra em maiúscula
n Para se precisar o significado pretendido para uma classe, deve-se explicar o que é (e não é ...) uma instância da classe
• Exemplo: “Um aluno é uma pessoa que está inscrita num curso ministrado numa escola. Uma pessoa que esteve no passado inscrita num curso, mas não está presentemente inscrita em nenhum curso, não é um aluno.”
• Em geral, o nome da classe não é suficiente para se compreender o significado da classe
Aluno Curso
11UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Atributos de instância
n O estado de um objecto é dados por valores de atributos (e por ligações que tem com outros objectos)
n Todos os objectos de uma classe são caracterizados pelos mesmos atributos (ou variáveis de instância)
• o mesmo atributo pode ter valores diferentes de objecto para objecto
n Atributos são definidos ao nível da classe, enquanto que os valores dos atributos são definidos ao nível do objecto
n Exemplos:• uma pessoa (classe) tem os atributos nome, data de nascimento e
peso• João (objecto) é uma pessoa com nome “João Silva”, data de
nascimento “18/3/1973” e peso “68 Kg”
12UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Atributos de instância
n Atributos são listados num compartimento de atributos (opcional) a seguir ao compartimento com o nome da classe
n Uma classe não deve ter dois atributos com o mesmo nome
n Os nomes dos tipos não estão pré-definidos em UML, podendo-se usar os da linguagem de implementação alvo
Pessoa
nome: stringdata de nascimento: datepeso: real = 75 kg
compartimento de atributos
valor inicial por omissão
classe
tipo de dados
nome do atributo
13UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Operações de instâncian Comportamento invocável de objectos é modelado por operações
• uma operação é algo que se pode pedir para fazer a um objecto de uma classe
n Objectos da mesma classe têm as mesmas operações
n Operações são definidos ao nível da classe, enquanto que a invocação de uma operação é definida ao nível do objecto
n Princípio do encapsulamento: acesso e alteração do estado interno do objecto (valores de atributos e ligações) controlado por operações
n Nas classes que representam objectos do mundo real é mais comum definir responsabilidades em vez de operações
Pessoa
nome: stringmorada: string
setMorada(novaMorada:string): boolcompartimento
de operações
14UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Atributos e operações estáticos (≠de instância)n Atributo estático: tem um
único valor para todas as instâncias (objectos) da classe
• valor está definido ao nível da classe e não ao nível das instâncias
n Operação estática: não é invocada para um objecto específico da classe
n Notação: nome sublinhado
n Correspondem a membros estáticos (static) em C++, C# e Java
Factura
número: Longdata: Datevalor: RealúltimoNumero: Long = 0
criar(data:Date, valor:Real)destruir()valorTotal(): Real
retorna a soma dos valores de todas as facturas
cria nova factura com a data e valor especificados, e um nº sequencial atribuído automaticamente com base em ultimoNumero
15UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Visibilidade de atributos e operaçõesn Visibilidade:
+ (public) : visível por todos
- (private) : visível só por operações da própria classe
# (protected): visível por operações da própria classe e descendentes (subclasses)
n Princípio do encapsulamento: esconder todos os detalhes de implementação que não interessam aos clientes (utilizadores) da classe
• permite alterar representação do estado sem afectar clientes
• permite validar alterações de estado
Toolbar
# currentSelection: Tool# toolCount: Integer
+ getTool(i: Integer): Tool+ addTool(t: Tool)+ removeTool(i: Integer)- compact()
usada internamente por outras operações
16UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
*Multiplicidade de classes e atributos
n Multiplicidade de classe: número de instâncias que podem existir
• por omissão, é 0..*
n Multiplicidade de atributo: número de valores que o atributo pode tomar do tipo especificado
• por omissão é 1
• qual a diferença em relação a especificar a multiplicidade no próprio tipo de dados do atributo?
NetworkController
consolePort [2..*]: Port
1
17UML – Diagramas de Classes– v.1.2, João Pascoal Faria, Outubro de 2002
Relações entre classes: associação, agregação e composição
18UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Associações binárias
n Uma associação é uma relação entre objectos das classes participantes (um objecto de cada classe em cada ligação)
n Não gera novos objectos
n Matematicamente,uma associação binária é uma relação binária, i.e., um subconjunto do produto cartesiano das extensões das classes participantes
n Assim como um objecto é uma instância duma classe, uma ligação é uma instância duma associação
n Pode haver mais do que uma associação (com nomes diferentes) entre o mesmo par de classes
n Papéis nos extremos da associação podem ter indicação de visibilidade (pública, privada, etc.)
Participante-1 Participante-2Nome da associaçãopapel-1 papel-2
19UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Multiplicidade de associações binárias
Muitos-para-Muitos 1-para-1Muitos-para-1
Professor Curso Aluno Curso Curso Plano de Curso
(sem restrições )
* 1 11**
20UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Notação para a multiplicidade
1 - exactamente um
0..1 - zero ou um (zero a 1)
* - zero ou mais
0..* - zero ou mais
1..* - um ou mais
1, 3..5 - um ou três a 5
21UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Associação reflexiva
n Pode-se associar uma classe com ela própria (em papéis diferentes)
Pessoapai
filho0..1
* filho
mãe0..1
*
22UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Nome de associação
n A indicação do nome é opcional
n O nome é indicado no meio da linha que une as classes participantes
n Pode-se indicar o sentido em que se lê o nome da associação
Empresa PessoaTrabalha-paraEmpregaempregador empregado
23UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Associações unidireccionais
As associações são classificadas quanto à navegabilidade em:bidireccionais(normal)unidireccionais
um objecto da classe 1 tem a responsabilidade de dar o(s) objecto(s) correspondente(s) da classe 2 (nível de especificação)
ouum objecto da classe 1 tem apontador(es) para o(s) objecto(s) correspondente(s) da classe 2 (nível de implementação)
Class-1 Class-2
Class-1 Class-2
24UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Classe-Associação
n reúne as propriedades de associação e classe
n o nome pode ser colocado num sítio ou noutro, conforme interessarealçar a natureza de associação ou de classe, mas a semântica é a mesma
n o nome também pode ser colocado nos dois sítios
n não é possível repetir combinações de objectos das classes participantes na associação
Class-1 Class-2
Association Name
link attribute...
link operation...
Association Name
25UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Associações n-áriasn Notação
n Multiplicidade
a cada par de objectos das restantes classes (1 e 2), correspondem 0 ou 1 objectos da classe 3
Class-1 Class-2
Association Name
role-1 role-2
Class-3role-3
Class-1 Class-2
Class-30..1
26UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Pertence a
Atributos versus Associações
n Uma propriedade que designa um objecto de uma classe presente no modelo, deve ser modelada como uma associação e não como um atributo
n Exemplo:
País Cidade
nome: string
capital: string
capital: Cidade
1
1
nome: string0..1
*
capital
27UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
*Associações qualificadas
n Qualificador: lista de um ou mais atributos de uma associação utilizados para navegar de A para B
n "Chave de acesso" a B (acesso a um objecto ou conjunto de objectos) a partir de um objecto de A
qualificadorClasse A Classe B
0..1nº de sócioClube Pessoa*
para cada par Clube + nº de sócio
Associação
nomemorada
uma Pessoa pode ser sócia de vários clubes
28UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Agregação
n Associação com o significado contém (é constituído por) / faz parte de (part of)
n Relação de inclusão nas instâncias das classes
n Hierarquias de objectos
n Exemplo:
Equipa
Jogador*0..1
• Uma equipa contém 0 ou mais jogadores
• Um jogador faz parte de uma equipa (num dado momento), mas também pode estar desempregado
29UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Composição
n Forma mais forte de agregação aplicável quando:• existe um forte grau de pertença das partes ao todo
• cada parte só pode fazer parte de um todo (i.e., a multiplicidade do lado do todo não excede 1)
• o topo e as partes têm tempo de vida coincidente, ou, pelo menos, as partes nascem e morrem dentro de um todo
• a eliminação do todo propaga-se para as partes, em cascata
n Notação: losango cheio (?♦) ou notação encaixada
n Membros-objecto em C++
30UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Window
Composição: notações alternativasWindow
Slider Header Panelscrollbar 2
1
title 1
1 1
1body
scrollbar: Slider 2
title: Header 1
body: Panel 1
(sub-objectos no compartimento dos atributos)
Window
scrollbar[2]: Slidertitle: Headerbody: Panel
31UML – Diagramas de Classes– v.1.2, João Pascoal Faria, Outubro de 2002
Relações entre classes: generalização
32UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Generalização
• Relação semântica “is a” (“é um” / “é uma”) : um aluno é uma pessoa
• Relação de inclusão nas extensões das classes:UoD
super-classe
sub-classe x xx
xx
objecto
extensão (sub-classe) ⊂ extensão (super-classe)
Pessoa
Aluno
generalização especialização
• Relação de herança nas propriedades: A sub-classe herda as propriedades (atributos, operações e relações) da super-classe, podendo acrescentar outras
super-classe
sub-classe
33UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
As três facetas da generalização
n Substitutabilidade• onde se espera um objecto da super-classe pode-se passar um
objecto duma subclasse
n Herança de interface• a subclasse herda as assinaturas (e significados) das operações da
super-classe
n Herança ou overriding de implementação• a subclasse pode herdar as implementações das operações da super-
classe, mas também pode ter novas implementações de algumas dessas operações
• quando em UML se repete numa subclasse a assinatura de uma operação da super-classe, quer dizer que tem uma nova implementação na subclasse
34UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Polimorfismo
n Substitutabilidade + Overriding ⇒ Polimorfismo + Late Binding
• Quando se tem uma variável do tipo referência ou apontador para super-classe (que pode guardar uma referência para objecto da super-classe ou de uma subclasse), e se invoca uma operação, é usada a implementação da classe do objecto referenciado (determinada em tempo de execução – late binding), e não a implementação de acordo com o tipo de referência (determinada emtempo de compilação – early binding)
• Em C++ e C# só acontece com funções ou métodos virtuais
n Mecanismo muito poderoso, que permite estender software através da criação de novas subclasses que são usadas a partir de classes pré-existentes (que dependem apenas da interface e não da implementação das operações), sem que estas tenham conhecimento dessas extensões
35UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Exemplo em C++class Pessoa {
private:string nome; Data dataNascimento;public:Pessoa(string, Data);string getNome() const;Data getDataNascimento() const;int getIdade() const;void setNome(string);void setDataNascimento(Data); virtual void imprime() const;
};
class Aluno : public Pessoa {private: string curso;
public:Aluno(string nm, Data, string crs);string getCurso() const;void setCurso(string);virtual void imprime() const;
};Ferramenta: Microsoft Visual Modeler
Pessoa
nome : str ingdataNasc imento : Data
Pessoa(str ing, Data)getNome() : s t r inggetDataNasc imento() : DatagetIdade() : intsetNome(str ing) : voidsetDataNascimento(Data) : voidimprime() : void
A luno
curso : string
Aluno(str ing nm, Data, str ing crs)getCurso() : str ingsetCurso(str ing) : voidimprime() : void
36UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Pessoa
nome : str ingdataNascimento : Data
Pessoa(string, Data)getNome() : stringgetDataNascimento() : DatagetIdade() : intsetNome(string) : voidsetDataNascimento(Data) : voidimprime() : void
Aluno
curso : string
Aluno(string nm, Data, string crs)getCurso() : stringsetCurso(string) : voidimprime() : void
Professor
categoria : string
Professor(string nm, Data, string ctg)getCategoria() : stringsetCategoria(string) : voidimprime() : void
AlunoDoutoramento
Hierarquias de classesn Em geral, pode-se
ter uma hierarquia de classes relacionadas por herança / generalização
• em cada classe da hierarquia colocam-se as propriedades que são comuns a todas as suas subclasses
⇒ evita-se redundância, promove-se reutilização! (...)
37UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Notações alternativas para hierarquias de classes
Aluno Professor
Pessoa
Aluno Professor
Pessoa
38UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Subclasses sobrepostas (≠disjuntas)
n caso em que um objecto da superclasse pode pertencer simultaneamente a mais do que uma subclasse
n indicado por restrição {overlapping}
n o contrário é {disjoint} (situação por omissão?)
Superclass
Subclass-1 Subclass-2
{overlapping}
ou Superclass
Subclass-1 Subclass-2
{overlapping}
39UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Subclasses incompletas (≠completas)
n caso em que um objecto da superclasse pode não pertencer a nenhuma das subclasses
n indicado por restrição {incomplete}
n o contrário é {complete} (situação por omissão?)
Técnico Comercial
Funcionário
{incomplete}
40UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Herança múltipla (≠simples)
n ocorre numa subclasse com múltiplas super-classes
n geralmente suportada por linguagens de programação OO
Estudante Professor
curso categoria
Académico
nomee-mail
Professor-Estudante
redução de horário
{overlapping} Só faz sentido assim!
pelo menos conceptualmente, existe uma super-classe comum
herda propriedades de Estudante e Professor e, indirectamente, de Académico (uma única vez!)
41UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Classificação dinâmica (≠estática)n classificar objecto: atribuir classe a objecto
n caso em que a(s) classe(s) a que um objecto pertence pode(m) variar ao longo da vida do objecto
n indicado por estereótipo «dynamic»
n geralmente não suportada por linguagens de programação OO
Pessoatarefa
Gestor
Engenheiro
Vendedor
«dynamic»
atributo discriminante (atributo de pessoa que indica a subclasse a que pertence)
Uma pessoa que num dado momento tem a tarefa de gestor, pode noutro momento ter a tarefa de vendedor, etc.
42UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Classificação múltipla (≠simples)
n caso em que um objecto pode pertencer num dado momento a várias classes, sem que exista uma subclasse que represente a intersecção dessas classes (com herança múltipla)
n geralmente não suportado pelas linguagens de programação OO (pode então ser simulada por agregação de papéis)
exemplo de combinação legal: {Mulher, Paciente, Enfermeira}
Homem
MulherPessoasexo
Paciente
paciente
funçãoMédico
Enfermeira
Fisioterapeuta
43UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Classes e operações abstractas (≠concretas)n Classe abstracta: classe que
não pode ter instâncias directas
• pode ter instâncias indirectas pelas subclasses concretas
n Operação abstracta: operação com implementação a definir nas subclasses
• uma classe com operações abstractas tem de ser abstracta
• função virtual pura em C++
n Notação : nome em itálico ou propriedade {abstract}
Icon
RectangularIcon ArbitraryIcon
origin: Point
display()getID(): Integer
height: Integerwidth: Integer
edge:LineCollection
display()isInside(p:Point):Bool
Button
display()
Fonte: The UML UserGuide, Booch et al
44UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Associação versus Agregação / Composição versus Generalização
Aluno
Pessoa
João
Maria
generalização
Cursos e disciplinas
Curso de Modelação de Software
UML
VDM++associação
agregação ou composição
objecto
classe
José
Professor
45UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Exemplo: meta-modelo parcial
Agregação
Composição
nomeClasse
Extremo de Associação 2..* 11 *
multiplicidadepapelvisibilidade
Associação
Classe -Associação
Relação
superclasse subclasse**
nome
Generalização
2 no caso de agregação
46UML – Diagramas de Classes– v.1.2, João Pascoal Faria, Outubro de 2002
Relações entre classes: dependência e concretização
47UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Relação de dependência
n Relação de uso entre dois elementos (classes, componentes, etc.), em que uma mudança na especificação do elemento usado pode afectar o elemento utilizador
n Exemplo típico: classe-1 que depende de outra classe-2 porque usa operações ou definições da classe-2
n Úteis para gestão de dependências
servidorcliente
48UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Relação de concretização (realization)n Relação entre elementos a diferentes níveis de abstracção, isto é,
entre um elemento mais abstracto (que especifica uma interface ou um "contracto", entre clientes e implementadores) e um elemento correspondente mais concreto (que implementa esse contracto)
n Difere da generalização porque há apenas herança de interface e não herança de implementação
«type»StackLinkedStack
«interface»ISerializableXMLDocument
Caso de utilizaçãoColaboração
49UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Dependência e concretização
n Aparecem frequentemente combinados
n Cliente usa o servidor sem dele depender directamente (depende apenas da interface ou contracto que o servidor implementa)
contracto ou interfacecliente
servidor
50UML – Diagramas de Classes– v.1.2, João Pascoal Faria, Outubro de 2002
Restrições, elementos derivados, pré-condições e pós-condições
51UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Restrições
n Uma restrição especifica uma condição que tem de se verificar no estado do sistema (objectos e ligações)
n Uma restrição é indicada por uma expressão ou texto entre chavetas ou por uma nota posicionada junto aos elementos a que diz respeito, ou a eles ligada por linhas a traço interrompido (sem setas, para não confundir com relação de dependência)
n Podem ser formalizadas em UML com a OCL - "ObjectConstraint Language"
n Também podem ser formalizadas (como invariantes) numa linguagem de especificação formal como VDM++
52UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Restrições em classesPessoa
nomedataNascimentolocalNascimentodataFalecimento
{chave candidata: (nome, dataNascimento, localNascimento)}{dataFalecimento > dataNascimento}
Factura LinhaFactura
*1númerodata
númeroartigoquantidadevalor
{chave candidata: (factura, número)}
{chave candidata: (número)}
53UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Restrições em associações
Pessoa Empresachefe
1*empregado empregador
subordinado0..1 *Pessoa.empregador = Pessoa.chefe.empregador
Pessoa ComitéMembro-de
Director-de
*
*
*1 {subset}
Factura LinhaFactura*
{ordered}
1
uma factura é constituída por um conjunto ordenado de 0 ou mais linhas
Conta
Pessoa
{xor}
Empresa
associações mutuamente exclusivas
54UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Elementos derivados
n Elemento derivado (atributo, associação ou classe): elemento calculado em função doutros elementos do modelo
n Notação: barra “/” antes do nome do elemento derivado
n Um elemento derivado tem normalmente associada uma restrição que o relaciona com os outros elementos
55UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Exemplo de elementos derivados
Movimento
datavalor
/ TotalMensal
mêsvalor
{valor = (select sum(valor) from Movimento where month(data)=mês)}
Empresa 1Departamento
*Pessoa
TrabalhaEmDepartamento1
/TrabalhaEmEmpresa
empregador1
*
{Pessoa.empregador = Pessoa.departamento.empresa}
*
dataNascimento/idade
{idade = dataActual() - dataNascimento}
56UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
* Pré-condições e pós-condições
n Semântica de operações pode ser captada através de pré-condições e pós-condições
n Pré-condição: uma condição nos argumentos e estado inicial do objecto, a verificar na chamada (início) da operação
n Pós-condição: uma condição nos argumentos, estado inicial do objecto, estado final do objecto e valor retornado pela operação, a verificar no retorno (fim) da operação
n Podem ser expressas em UML através da OCL (Object ConstraintLanguage)
n Também podem ser expressas numa linguagem de especificação formal, como VDM++
• VDM++ tem a vantagem de permitir também implementar as operações e executar as pré-condições e pós-condições
57UML – Diagramas de Classes– v.1.2, João Pascoal Faria, Outubro de 2002
Classes especiais: classes parametrizadas, interfaces, tipos, meta-classes, utilitários
58UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
* Classes parametrizadas (templates)
FArrayTk: Integer
parâmetros formais
data [k] : T
ThreePoints
«bind» (Point,3)
classe parametrizada
parâmetros actuais
Farray<Point,3>ou
template <class T, int k> class FArray { public: T[k] data; };
typedef Farray<Point,3> ThreePoints;
≠ generalização, porque não se podem acrescentar propriedades!
classe ligada ("bound")C++
59UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Interfacesn Uma interface especifica um conjunto de operações (com sintaxe
e semântica) externamente visíveis de uma classe de (ou componente, subsistema, etc.)
• semelhante a classe abstracta só com operações abstractas e sem atributos nem associações (em C++ é mesmo isso!)
• separação mais explícita entre interface e (classes de) implementação• interfaces são mais importantes em linguagens como Java, C# e VB.NET que
têm herança simples de implementação e herança múltipla de interface
n Relação de concretização de muitos parta muitos entre interfacese classes de implementação
n Vantagem em separar interface de implementação: os clientes de uma classe podem ficar a depender apenas da interface em vez da classe de implementação
n Notação: classe com estereótipo «interface» (ligada por relação de concretização à classe de implementação) ou círculo (ligado por linha simples à classe de implementação)
60UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Interfaces: notações alternativas
«interface»InterfaceClass
ImplementationClassImplementationClass
InterfaceClassoperations
ClientClass
attributes
operations
attributes
operations
ou
ClientClassCliente depende só da interface e não da implementação
relação de concretização
61UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
* Tiposn Um tipo é usado para especificar um domínio de objectos em
conjunto com as operações aplicáveis a esses objectos, sem especificar a implementação física desses objectos
• não pode incluir métodos (implementação de operações)• pode ter atributos e associações (abstractos!), mas apenas para especificar o
comportamento das operações, sem compromisso de implementação• notação: classe com estereótipo «type»• semelhante a tipo abstracto de dados
n Uma classe de implementação (classe normal) define a estrutura física de dados (para atributos e associações) e métodos de um objecto tal como é implementado numa linguagem tradicional
• notação: classe normal ou classe com estereótipo «implementationClass»• diz-se que uma classe de implementação concretiza ("realizes") um tipo se
proporciona todas as operações definidos no tipo, com o mesmo comportamento especificado no tipo
62UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
* Tipos: exemplo
«type»FinitePriorityQueue
isFull():Boolean
maxSize:Integer «type»PriorityQueue
insert(value:T, priority:Integer)deleteMax():TisEmpty():Boolean
T
HeapFinitePriorityQueue
+ insert(value: T, priority: Integer)+ deleteMax():T+ isEmpty(): Boolean+ isFull(): Boolean- HeapifyUp- HeapifyDown
TmaxSize:Integer
- elems [0..maxSize]: T- size: Integer = 0
HeapFilaPacientes
«bind» (Paciente, 100)
elems: set of (priority: Integer,value:T)
relação de concretização
63UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
* Meta-classes
n Uma meta-classe é uma classe cujas instâncias são classes
n Notação: classe com estereótipo «metaclass»
n Usadas geralmente em meta-modelos
n Relação de instanciação (entre classe e meta-classe) pode ser indicada por dependência com estereótipo «instanceOf»
«metaclass»SYSCLASSES
name
Class-1«instanceOf»
64UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
* Utilitários
n Um utilitário é um agrupamento de variáveis globais e procedimentos como classe
n Pode ser implementado por classe em que todos os atributos e operações são estáticos
n Notação: classe com estereótipo «utility»
«utility»MathPack
pi: Real
sin(ang: Real): Realcos(ang: Real): Real
65UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
* Estereótipos de classes em modelos de negócio
actor em relação ao negócio (cliente ou outra entidade ou sistema que interage com o negócio);actor externo
perfil de trabalhador do negócio, interno (não interage com actores do negócio) ou de fronteira (interage com actores do negócio);actor interno
objecto passivo manipulado pelos trabalhadores e actores nas actividades dos processos de negócio
Um modelo de negócio descreve a implementação dos processos de negócio (de fronteira) e de suporte (internos) através de colaborações entre objectos dos seguintes tipos:
business actor
business worker
business entity
66UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
* Estereótipos de classes em modelos de análise
control
boundary
entity
actor
Um modelo de análise descreve implementações "ideais" dos casos de utilização de um sistema de software, com vista a melhor compreender os seus requ isitos, através de colaborações entre objectos dos seguintes tipos:
actor em relação ao sistema de software (pode ser interno ou externo ao negócio)
objecto de fronteira (formulário, janela, etc.)
objecto passivo que guarda estado mais ou menos persistente
objecto de controlo (controla sequência de funcionamento, transacções, etc.; estabelece ligação entre objectos de fronteira e entidades)
67UML – Diagramas de Classes– v.1.2, João Pascoal Faria, Outubro de 2002
Caso de estudo e exercícios
68UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Caso de estudo (Biblioteca): modelo de domínio
Sócionúmeronomemoradatelefonedata de inscriçãovalidade da inscriçãoestado : (activo,inactivo)
Requisiçãonúmerodata de requisiçãoprazo de devoluçãodata de devolução
1
*
1
*
Autornomenacionalidade
Biblioteca
nomemoradatelefone
1
*
1
*Publicaçãoisbnnº de patrimóniotítuloanoeditoradata de aquisiçãocustocontador de consultas/ estado : (disponível,emprestada)
1
*
1
*
* ** *
1*
1*
Só se considera a existência dma instância
69UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Caso de estudo (Biblioteca): modelo de desenho - camada de lógica de negócio
Biblioteca
nomemoradatelefone
estatísticaUtilização()
(from Lógica de Negócio - Recursos)
Autor
nomenacionalidade
<<static>> registarAutor(nome, nacionalidade)<<static>> procurarAutor(nome, nacionalidade) : Autor<<static>> listarAutores(filtro)
(from Lógica de Negócio - Recursos)
Sócio
número : intnome : stringmorada : stringtelefone : intdata de inscriçãovalidade da inscrição/ estado : (activo,inactivo)
<<static>> registarSócio(nome, morada, telefone) : int
(from Lógica de Negócio - Clientes)
Requisição
número : intdata da requisição : date : = curdateprazo de devolução : datedata da devolução : date
registarDevolução(data)<<static>> registarRequisição(publicação, sócio)
(from Lógica de Negócio - Clientes) 1*
1*
Publicação
isbntítuloanoeditoradata da aquisiçãocusto/ estado : (disponível, emprestada)contador de utilizações : int : = 0
<<static>> registarPublicação(isbn, título, autores)<<static>> listarPublicações(filtro)
(from Lógica de Negócio - Recursos)
** **
1
*
1
*
A rever!
70UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Exercício 1
n Refinar o caso de estudo (modelo de domínio e modelo de desenho da camada de lógica de negócio) de acordo com os seguintes requisitos:
• Uma publicação pode ter vários exemplares
• Uma publicação pode ser um livro ou uma revista.
• Uma revista contém artigos, sendo os autores definidos artigo a artigo
• As publicações podem ser agrupadas em colecções; nesse caso, a editora é definida ao nível da colecção
• Possibilidade de ficarem requisições em lista de espera
n Refinar o modelo de domínio com restrições de integridade
n Elaborar modelos de análise e de negócio
71UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Exercício 2
n (ASI 24/4/97) Um jornal desportivo pretende manter informação relativa a diversos campeonatos de futebol (1º divisão nacional,2ª divisão nacional, campeonatos regionais, etc.), de acordo como seguintes pressupostos:
• Em cada campeonato participam várias equipas. • Cada campeonato está organizado numa sequência de jornadas. • Numa jornada de um campeonato realizam-se diversos jogos em paralelo em
que se defrontam todas as equipas duas a duas (um equipa visitada e uma equipa visitante em cada jogo).
• Cada equipa participa num e num só jogo por jornada. • Relativamente a cada jogo interessa saber a data-hora e local da sua
realização, o árbitro, o resultado do jogo, os jogadores efectiv os, e eventos importantes (com o tempo em que ocorreram e a indicação dos jogadores envolvidos), tais como golos, cartões, expulsões e substituições .
n Elabore um diagrama de classes relativamente a esta realidade, com atributos e relações entre classes
72UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Exercício 3
n Elaborar um diagrama de classes em UML relativo a um módulo que permite construir passo a passo interrogações simples (queries) em SQL, de acordo com as seguintes requisitos:
• As interrogações que interessa tratar são da forma:selectcoluna1, ..., colunanfrom tabela1 alias1, ..., tabelam aliasmwhere ( .... and .... and ...) or ... or ( .... and .... and ...)order by coluna1 asc/desc, ..., colunak asc/desc
• As partes de where e order by são opcionais. • Na parte de selectapenas se admite uma lista de nomes de colunas e não
expressões genéricas. • Na parte de from apenas se indica uma lista de nomes de tabelas. A seguir ao
nome de uma tabela pode-se indicar um alias (nome a usar localmente na interrogação). A mesma tabela pode aparecer mais do que uma vez na parte de from, com aliases diferentes.
• A parte de where está na forma normal disjuntiva (disjunção de conjunções). Os operandos da conjunção são termos ou termos negados (precedidos de not). Cada termo aplica um operador de comparação a um ou mais operandos.
73UML – Diagramas de Classes – v.1.2, João Pascoal Faria, Outubro de 2002
Exercício 3 (cont.)• Os operadores de comparação com um operando são is null e is not null. Os
operadores de comparação com dois operandos são =, <>, >, >=, <, <=, like e not like. O único operador de comparação com três operando é o operador between ... and .
• Um operando é uma constante (número ou string) ou uma referência a uma coluna de uma tabela mencionada na parte de from.
• As classes devem disponibilizar operações para: - registar (adicionar) uma tabela- registar uma coluna numa tabela- criar um query inicialmente vazio- preencher um query incrementalmente:
- adicionar uma tabela à parte de from de um query (as tabelas são adicionadas uma a uma)- adicionar uma coluna à parte de select de um query (as colunas são adicionadas uma a uma)- adicionar uma coluna à parte de order by de um query (as colunas são adicionadas uma a
uma)- acrescentar uma conjunção (inicialmente vazia) à parte de where- criar um termo e acrescentá-lo a uma conjunção da parte de where
- obter o query em string em SQL- obter o query em string em XML
• Opcionalmente, implementar em Java, C# ou VB.NET e escrever um pequeno programa de teste