Transcript
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Engenharia de software Lu´ıs A. Alexandre
UBI, 14 de Abril de 2008
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Conte´udo
I
Classes.
I
Rela¸c˜oes.
I
Coment´arios.
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Classes Atributos Opera¸c˜ oes Contexto
Classes
I
Elemento mais importante num sistema OO. ´ uma descri¸c˜ao de um conjunto de objectos que partilham os E mesmos atributos, opera¸c˜ oes e rela¸c˜ oes.
I
Uma classe implementa um ou mais interfaces.
I
As classes podem representar objectos de software (janela, bot˜ao), objectos de hardware (sensor, interruptor) ou entidades puramente abstractas (forma bidimensional).
I
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Classes Atributos Opera¸c˜ oes Contexto
Representa¸c˜ao das classes
I
Em UML a representa¸c˜ao de uma classe pode ser feita a diferentes n´ıveis: o mais simples consiste em representar apenas o nome da classe. NomeDaClasse
I
Os nomes das classes devem come¸car por mai´ usculas e quando s˜ao compostos por mais de uma palavra, a primeira letra de cada palavra deve ser mai´ uscula.
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Classes Atributos Opera¸c˜ oes Contexto
Representa¸c˜ao dos atributos I I
Os atributos representam-se por baixo do nome da classe. Pode apenas ser escrito o nome de um atributo ou pode ser colocada tamb´em informa¸c˜ao relativa ao seu tipo. Cliente nome : String morada : String numeroTelefone : long
I
Os nomes dos atributos devem come¸car por min´ usculas e quando s˜ao compostos por mais de uma palavra, a primeira letra de cada palavra deve ser mai´ uscula (exceptuando a primeira). Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Classes Atributos Opera¸c˜ oes Contexto
Representa¸c˜ao das opera¸c˜oes I I
As opera¸c˜oes representam-se por baixo dos atributos. Pode apenas ser escrito o nome da opera¸c˜ao ou pode ser colocada tamb´em informa¸c˜ao relativa ao tipo de dados que devolve, ou pode ainda ser colocada informa¸c˜ao relativa aos parˆametros que recebe e seus tipos. Cliente nome : String morada : String numeroTelefone : long getNome() : String setNome(novoNome : String) : void
I
Os nomes das opera¸c˜ oes seguem as mesmas regras dos nomes dos atributos. Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Classes Atributos Opera¸c˜ oes Contexto
Representa¸c˜ao dependente do contexto I
A forma usada para representar as classes depende do seu fim. Se estivermos numa fase de an´alise ent˜ao deve ser usada uma representa¸c˜ao simplificada:
I
Na fase de desenho devem ser inclu´ıdos mais detalhes: Cliente nome : String morada : String numeroTelefone : long
Cliente
getNome() : String setNome(novoNome : String) : void
Cliente
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes
entre classes de dependˆ encia de generaliza¸c˜ ao de associa¸c˜ ao de associa¸c˜ ao: nome de associa¸c˜ ao: papel de associa¸c˜ ao: multiplicidade de associa¸c˜ ao: agrega¸c˜ ao
Rela¸c˜oes entre classes
I
As classes est˜ao relacionadas usando as rela¸c˜oes que j´a estud´amos para os casos de uso: dependˆencia, associa¸c˜ao e generaliza¸c˜ao.
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes
entre classes de dependˆ encia de generaliza¸c˜ ao de associa¸c˜ ao de associa¸c˜ ao: nome de associa¸c˜ ao: papel de associa¸c˜ ao: multiplicidade de associa¸c˜ ao: agrega¸c˜ ao
Rela¸c˜oes de dependˆencia
I
A rela¸c˜ao de dependˆencia indica que uma classe usa a outra.
I
Esta rela¸c˜ao ´e normalmente usada quando uma classe ´e usada como argumento numa opera¸c˜ao de outra classe.
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes
entre classes de dependˆ encia de generaliza¸c˜ ao de associa¸c˜ ao de associa¸c˜ ao: nome de associa¸c˜ ao: papel de associa¸c˜ ao: multiplicidade de associa¸c˜ ao: agrega¸c˜ ao
Rela¸c˜oes de generaliza¸c˜ao I
A generaliza¸c˜ao ´e uma rela¸c˜ao entre uma classe geral (a super-classe ou pai) e uma ou mais classes mais espec´ıficas (sub-classes ou filhos).
I
As classes filho herdam todos os atributos e opera¸c˜oes da classe pai e podem ter mais atributos e opera¸c˜oes que aqueles que herdam.
I
Se uma opera¸c˜ao num filho tem o mesmo nome da do pai est´a a fazer um override `a do pai.
I
Exemplo geom´etrico: forma, pol´ıgono, rectˆangulo, quadrado, elipse, circunferˆencia, triˆangulo. Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes
entre classes de dependˆ encia de generaliza¸c˜ ao de associa¸c˜ ao de associa¸c˜ ao: nome de associa¸c˜ ao: papel de associa¸c˜ ao: multiplicidade de associa¸c˜ ao: agrega¸c˜ ao
Rela¸c˜oes de generaliza¸c˜ao
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes
entre classes de dependˆ encia de generaliza¸c˜ ao de associa¸c˜ ao de associa¸c˜ ao: nome de associa¸c˜ ao: papel de associa¸c˜ ao: multiplicidade de associa¸c˜ ao: agrega¸c˜ ao
Rela¸c˜oes de associa¸c˜ao I I
A associa¸c˜ao ´e uma rela¸c˜ao estrutural entre duas classes. ´ poss´ıvel ter ambas as termina¸c˜ E oes duma associa¸c˜ao na mesma classe: significa que podemos ligar v´arios objectos da mesma classe uns aos outros.
I
Uma rela¸c˜ao apenas entre duas entidades diz-se bin´aria.
I
Podem existir rela¸c˜ oes n-´arias.
I
As rela¸c˜oes de associa¸c˜ao podem ser complementadas por 4 tipos de adornos: nome, papel, multiplicidade e agrega¸c˜ao. Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes
entre classes de dependˆ encia de generaliza¸c˜ ao de associa¸c˜ ao de associa¸c˜ ao: nome de associa¸c˜ ao: papel de associa¸c˜ ao: multiplicidade de associa¸c˜ ao: agrega¸c˜ ao
Nome
I
´ poss´ıvel atribuir um nome a uma associa¸c˜ao para descrever E a natureza da associa¸c˜ao.
I
Por vezes usa-se uma seta ao lado do nome a indicar em que sentido funciona o nome da associa¸c˜ao: no caso acima poderia ter uma seta da esquerda para a direita.
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes
entre classes de dependˆ encia de generaliza¸c˜ ao de associa¸c˜ ao de associa¸c˜ ao: nome de associa¸c˜ ao: papel de associa¸c˜ ao: multiplicidade de associa¸c˜ ao: agrega¸c˜ ao
Papel I
Quando uma classe participa numa associa¸c˜ao representa um determinado papel. O nome desse papel pode ser colocado explicitamente junto da classe onde a linha da associa¸c˜ao termina.
I
De notar que uma mesma classe pode representar pap´eis diferentes em associa¸c˜ oes diferentes (a ”Pessoa”pode tamb´em representar o papel de um contribuinte para o estado).
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes
entre classes de dependˆ encia de generaliza¸c˜ ao de associa¸c˜ ao de associa¸c˜ ao: nome de associa¸c˜ ao: papel de associa¸c˜ ao: multiplicidade de associa¸c˜ ao: agrega¸c˜ ao
Multiplicidade I
Pode ser indicada a multiplicidade na rela¸c˜ao de associa¸c˜ao.
I
A falta de indica¸c˜ao significa que n˜ao foi definida (n˜ao existe nenhum valor atribu´ıdo).
I
Podem ser combinados v´arios s´ımbolos numa lista (cada s´ımbolo separado por v´ırgula do seguinte): 1..3,5
I
Exemplo: edif´ıcio, telhado, chamin´e, porta. Lu´ıs A. Alexandre
S´ımbolo 0..1 1 0..∗ 1..∗ n 0..n 1..n n..m n..∗
Significado Zero ou um Apenas um Zero ou mais Um ou mais Apenas n (n> 1) Zero a n (n>1) Um a n (n>1) n a m (n>1,m>n) n ou mais (n>1)
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes
entre classes de dependˆ encia de generaliza¸c˜ ao de associa¸c˜ ao de associa¸c˜ ao: nome de associa¸c˜ ao: papel de associa¸c˜ ao: multiplicidade de associa¸c˜ ao: agrega¸c˜ ao
Multiplicidade: exemplo
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes Rela¸c˜ oes
entre classes de dependˆ encia de generaliza¸c˜ ao de associa¸c˜ ao de associa¸c˜ ao: nome de associa¸c˜ ao: papel de associa¸c˜ ao: multiplicidade de associa¸c˜ ao: agrega¸c˜ ao
Agrega¸c˜ao I
I
Quando queremos representar uma rela¸c˜ao do tipo ”todo/parte”, ou seja, em que as classes n˜ao se encontram ao mesmo n´ıvel e uma delas (o ”todo”) ´e constitu´ıda por v´arias ”partes”, ´e usada a agrega¸c˜ao. ´ uma rela¸c˜ao do tipo ”tem”: E objectos do tipo ”todo” tˆem objectos do tipo ”parte”. Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Coment´arios
I
Qualquer diagrama UML pode receber um coment´ario (ou nota).
I
Um coment´ario serve para tornar mais expl´ıcito algum ponto do diagrama.
I
N˜ao alteram o significado do que est´a representado!
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Leituras complementares Question´ ario
Leituras complementares
I
Booch: cap. 4, 5, 8
I
Fowler: cap. 4
I
Nunes: sec. 3.1
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Leituras complementares Question´ ario
Question´ario 1. O que significa a indica¸c˜ao 0..1, 3..4, 6..* sobre uma liga¸c˜ao de associa¸c˜ao ? 2. Represente num diagrama de classes a rela¸c˜ao entre a classe que representa os professores e a que representa as disciplinas, considerando que cada disciplina tem de ter pelo menos um docente e que cada docente lecciona pelo menos uma disciplina. 3. Modifique o diagrama anterior para representar o facto de poderem existir disciplinas em que n˜ao existe nenhum docente atribu´ıdo (n˜ao funcionam). 4. Modifique o diagrama anterior para representar o facto de uma disciplina poder ser leccionada no m´aximo por 2 docentes. Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Leituras complementares Question´ ario
Question´ario 5. Modifique o diagrama anterior para representar o facto de um departamento ser constitu´ıdo por professores e ser respons´avel por disciplinas. 6. Modifique o diagrama anterior para representar os alunos. Estes podem frequentar uma ou mais disciplinas. 7. Modifique o diagrama anterior para representar a classe faculdade. Os alunos est˜ao inscritos numa s´ o faculdade que pode ter qualquer n´ umero de alunos e ´e constitu´ıda por departamentos.
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Leituras complementares Question´ ario
Question´ario
8. Modifique o diagrama de forma a que possam existir disciplinas sem alunos inscritos. 9. Modifique o diagrama de forma a que possam existir professores que sejam presidentes de departamentos. 10. Modifique o diagrama para que possam existir professores que n˜ao leccionam disciplinas.
Lu´ıs A. Alexandre
Engenharia de software
Classes Rela¸c˜ oes Coment´ arios Conclus˜ ao
Leituras complementares Question´ ario
Question´ario
11. Olhando apenas para o diagrama final, escreva toda a informa¸c˜ao que retira dele.
Lu´ıs A. Alexandre
Engenharia de software
