uml – diagramas de classes - paginas.fe.up.ptjpf/teach/poo/classes.pdfuml –diagramas de classes...

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


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


Objectos, classes, atributos e operações


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


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)


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, ...}


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


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


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


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”


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


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


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


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


*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


Relações entre classes: associação, agregação e composição


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


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**


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


Associação reflexiva

n Pode-se associar uma classe com ela própria (em papéis diferentes)

Pessoapai

filho0..1

* filho

mãe0..1

*


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


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


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


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


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


*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


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


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++


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


Relações entre classes: generalização


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


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


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


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


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! (...)


Notações alternativas para hierarquias de classes

Aluno Professor

Pessoa

Aluno Professor

Pessoa


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}


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}


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


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.


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


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


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


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


Relações entre classes: dependência e concretização


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


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


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


Restrições, elementos derivados, pré-condições e pós-condições


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++


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


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


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


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}


* 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


Classes especiais: classes parametrizadas, interfaces, tipos, meta-classes, utilitários


* 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++


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)


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


* 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


* 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


* 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»


* 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


* 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


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


Caso de estudo e exercícios


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


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)


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)


** **

1

*

1

*

A rever!


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


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


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.


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

uml – diagramas de classes - paginas.fe.up.ptjpf/teach/poo/classes.pdfuml –diagramas de classes...

Documents