简体   繁体   English

UML 到 Java 代码

[英]UML to java code

I trying to understand UML class diagrams, but i am not sure if I do ... Lets assume that we have an UML class diagram like this (only required attributes are shown in each class):我试图理解 UML 类图,但我不确定我是否理解......让我们假设我们有一个这样的 UML 类图(每个类中只显示必需的属性):UML类图

The java code for that UML class diagram above should look like this (if I'm not wrong)上面那个 UML 类图的 java 代码应该是这样的(如果我没记错的话)

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

The question is : Am I correct ?问题是:我说得对吗? Do I udnerstand it well ?我听得懂吗?

Here:这里:

class Gearbox {
    enum Gearbox {
    automatic, manual;
    }
}

That better be:最好是:

enum Gearbox { AUTOMATIC, MANUAL; }

There is "no" point in wrapping an enum into a class of the same name in Java.将枚举包装到 Java 中的同名类中没有任何意义。

And from a "modeling" perspective, I would use enums also for location and brand.从“建模”的角度来看,我也会将枚举用于位置和品牌。 There is again "no" point in having a brand "class" that has fields called BMW or Skoda.拥有一个名为 BMW 或 Skoda 的领域的品牌“类”再次“没有”意义。 A car has exactly "one" brand out of a known disjunkt set of possibilities and enums exist to express exactly such situations.汽车在已知的不连续的一组可能性中具有完全“一个”品牌,并且存在枚举来准确表达此类情况。

Your implementation (except that enum thing) matches the diagram.您的实现(除了枚举之外)与图表相匹配。 Yes, But for me correctness also implies that the "big picture" works out.是的,但对我来说,正确性也意味着“大局”是可行的。 And as explained: your input is inherently flawed.正如所解释的:您的输入本质上是有缺陷的。 You managed to "correctly" express that input with Java source code.您设法使用 Java 源代码“正确地”表达了该输入。 So you solved the assignment (imho).所以你解决了任务(恕我直言)。 But in the real world I would sent you back home and have you rework the diagram first.但在现实世界中,我会把你送回家,让你先重新制作图表。

Coming from there, the real answer is: review the UML diagram first.从那里开始,真正的答案是:首先查看 UML 图。 It doesn't make sense this way.这种方式没有意义。 So instead of blindly implementing what is given to you - challenge requirements that are obviously inconsistent.因此,不要盲目地执行给你的东西——挑战明显不一致的要求。

Apart from the Gearbox not needing a class wrap (use a simple enum), the implementation is correct, however the diagram is not correct to begin with.除了 Gearbox 不需要类包装(使用简单的枚举)之外,实现是正确的,但是图表一开始就不正确。

In your proposed implementation you can notice that you are actually treating Location and Brand as a pseudo-enums;在您提议的实现中,您可以注意到您实际上将 Location 和 Brand 视为伪枚举; either use a class meaningfully, or use an enum.要么有意义地使用类,要么使用枚举。 This kind of pseudo concept is just confusing.这种伪概念只是令人困惑。

Try to follow Java naming conventions when writing code (so brandName instead of brand_name, etc.)编写代码时尽量遵循 Java 命名约定(因此,brandName 而不是 brand_name 等)

1) No association to Gearbox 1) 与变速箱无关联

You shouldn't specify an association to an enumeration (the same for primitive types such as String, int, etc.), instead use an attribute.您不应指定与枚举的关联(对于 String、int 等原始类型也是如此),而应使用属性。

Furthermore you should not the visibility (public, private, ...) for enum literals.此外,您不应该看到枚举文字的可见性(公共、私有、...)。 In fact UML doesn't even allow you to specify that, because the "attributes" in enumerations are actually different concepts from attributes in classes.事实上,UML 甚至不允许您指定它,因为枚举中的“属性”实际上是与类中的属性不同的概念。

在此处输入图片说明

2) brand_name is odd 2)brand_name 是奇数

A car is manufactured under a brand, which has a name.汽车是在一个品牌下制造的,这个品牌有一个名字。 However it is better to model the brand as a separate entity with a name attribute, rather than having a "brand_name" association, or an enum.但是,最好将品牌建模为具有名称属性的单独实体,而不是具有“brand_name”关联或枚举。

在此处输入图片说明

If you want to preserve the brand_name "access", you can add a method that will get you the value, eg如果你想保留brand_name“访问”,你可以添加一个方法来获取你的价值,例如

在此处输入图片说明

3) The same for location; 3)位置相同; location might have more attributes than a country;位置可能比国家有更多的属性; maybe address, maybe points of contacts, etc. So treat it as yet another modeling concept.也许是地址,也许是联系点,等等。所以把它当作另一个建模概念。

4) Do not use shared association if you don't specify what it means 4)如果你没有指定它的含义,不要使用共享关联

Shared association (empty rhombus) in UML has no specified meaning, which makes it flexible, but if you use it without specifying the meaning, it means nothing. UML中的共享关联(空菱形)没有明确的含义,这使得它具有灵活性,但是如果不指定含义就使用它,则没有任何意义。 So use association instead.所以改用关联。

在此处输入图片说明

I hope I understood object oriented design and programming with UML correct in the following way.:我希望我通过以下方式正确理解了使用 UML 的面向对象设计和编程:

class Car {
    /*+-----+     +-------+
      | Car |<>---| Brand |
      +-----+     +-------+*/
    private Brand brand;

    /*+-----+1    1+--------+
      | Car |◆----| Gearbox |
      +-----+      +--------+*/
    /*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
    }
}

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM