UML para código java
o código java para esse diagrama de classes UML acima deve ser parecido com este (se eu não estiver errado)
class Car {
private String color;
private int weight;
private Gearbox gearbox;
private Brand brand_name;
}
class Brand {
private String Skoda;
private String BMW;
private Location location;
}
class Location {
private String US;
private String EU;
}
class Gearbox {
enmu Gearbox {
automatic, manual
}
}
3 answers
class Gearbox {
enmu Gearbox {
automatic, manual
}
}
enum Gearbox { AUTOMATIC, MANUAL; }
Existe Não ponto em envolver um enum numa classe com o mesmo nome em Java.
E de uma perspectiva de modelagem {[[9]}, eu usaria enums também para localização e marca. Há outra vez No ponto em ter uma marca classe que tem campos chamados BMW ou Skoda. Um carro tem exatamente uma marca de um conjunto de possibilidades conhecido de disjunkt. E existem enums para expressar exatamente tal situacao.
A sua implementação (excepto aquela coisa enum) corresponde ao diagrama. Sim. Mas para mim a correção também implica que o" grande quadro " funciona. E como explicado: sua entrada é inerentemente imperfeita. Você conseguiu expressar "corretamente" Essa entrada com o código fonte Java. Então resolveu a tarefa (imho). Mas no mundo real eu mandava-te de volta para casa e fazia-te refazer o diagrama primeiro.
Vindo de lá, a resposta real é: reveja o diagrama de UML primeiro. Não faz sentido assim. Portanto, em vez de aplicar cegamente o que lhe é dado - desafie requisitos que são obviamente inconsistentes.
Para além da caixa de velocidades que não necessita de uma mudança de classe (use um enum simples), a implementação está correcta, no entanto o diagrama não está correcto para começar.
Na sua implementação proposta, pode notar que está a tratar a localização e a marca como um pseudo-enums; ou usa uma classe significantemente, ou usa um enum. Este tipo de pseudo conceito é apenas confuso.
Tente seguir as Convenções de nomes de Java ao escrever o código (por isso, o nome da marca em vez do nome da marca), etc.)
Nenhuma associação à caixa de Velocidades
Você não deve especificar uma associação a uma enumeração (o mesmo para tipos primitivos como String, int, etc.), em vez de usar um atributo.
Além disso, não deve ter visibilidade (pública, privada, etc.)...) for enum literals. Na verdade UML não permite que você especifique isso, porque os "atributos" em enumerações são na verdade conceitos diferentes de atributos em classes.
2) brand_name é estranho
Um carro é fabricado sob uma marca, que tem um nome. No entanto, é melhor modelar a marca como uma entidade separada com um atributo de nome, em vez de ter uma associação "brand_name", ou um enum.
Se quiser preservar o nome da marca "access", pode adicionar um método que lhe dará o valor, por exemplo
3) o mesmo para a localização; a localização pode ter mais atributos do que um país; talvez endereço, talvez pontos de contato, etc. Trata - o como mais um conceito de modelo.
4) não utilize a associação partilhada se não especificar o que significa
A Associação Partilhada (losango vazio) em UML não tem significado específico, o que a torna flexível, mas se a usar sem especificar o significado, não significa nada. Então use associação em vez disso.
class Car {
/*+-----+ +-------+
| Car |<>---| Brand |
+-----+ +-------+*/
private Brand brand;
/*+-----+ 1 1 +-------+
| Car |◆----| Brand |
+-----+ +-------+*/
/*Understood as composition (black diamond operator).
That means if there is no car there can't be a gearbox (inside of the car).*/
private Gearbox gearbox;
private String color;
private int weight;
private Brand brand_name;
}
class Brand {
/*+-------+ 1 1..n +----------+
| Brand |<>----------| Location |
+-------+ +----------+*/
List<Location> locations; //at least one location
private String Skoda;
private String BMW;
private Location location;
}
class Location {
private String US;
private String EU;
}
class Gearbox {
enmu Gearbox {
automatic, manual
}
}