UML软件设计（特别是抽象类）

Question

设计软件（例如UML图）和现实世界对象时。

如何为Abstract类确定合适的案例？

例如，如果我们有[员工]和[消防员]和[paidFireman]以及[unpaidFireman] ......我很难看到消防员或员工是否应该是抽象的，为什么？

Answer 1

抽象类有很多用途。抽象类是不能有任何直接实例的类。

在软件设计中，它是描述界面的一种方式。一些声明的操作可以在超类中实现。必须在子类中指定任何剩余的实现。无论实现存在于何处，抽象类都意味着不能存在直接实例，只能存在某些非抽象子类的实例。

在域分析中，抽象类是一种抽象建模方法。例如，考虑抽象Role。有用的是说Person会播放一些Roles。但是，没有Role的实例是有意义的，没有它也是Role的更具体的类型，例如Employee，Fireman或{{1 }}。对于这种情况，您不仅希望Teacher是抽象的，还需要covering axiom。有关详情，请阅读https://stackoverflow.com/a/35950236/2596664。

Answer 2

抽象类是UML中更深奥的构造之一。由于类已经是现实世界事物的抽象，因此抽象类甚至更高一级。抽象类无法实例化（因为假设它们错过了现实生活中的某些东西）。无论你说Fireman是抽象的而付费/未付的是抽象的，都是纯粹的观点，必须在特定领域加以论证。

根据经验：将抽象课程留在门外，直到你觉得迫切需要它为止。引入抽象性限制了您的模型（并且可以帮助避免一些格式错误的结果）。但是没有这些限制，只要建筑师遵守常识规则，模型仍然有效。

Answer 3

这主要取决于您的功能要求。

• 如果你的应用程序只是为了拥有简单的员工（没有将他们指定为消防员，警察或工匠），那么这个类可能不是抽象的，因为应用程序必须只是员工班。

• 如果这没有意义，即在创建时需要知道每个员工的职业，就会考虑抽象类。但在每种情况下，它们都不是必需的。确保占领已知的最简单方法是将其建模为强制属性。如果每个子类都有专门的行为，那么引入子类才有意义。例如，如果消防员的工资计算为50$ * count of the fires he exstinguished，但警察的工资为1000$ + 50 * rank，那么您在Employee类中建模抽象操作getSalary()，这将是具体指定并实施在每个子类中。

• 由于在其中一个答案中也提到了接口的概念，接口描述了在实现该接口的所有类中实现某些操作的义务。这与抽象类中的抽象操作非常相似。但是抽象类可以包含的不仅仅是接口：属性和非抽象操作。

因此，经验法则是：对于可以完全描述接口和行为的域的概念，请使用非抽象类。对于只能描述接口和无行为的概念，请使用接口。对于可以描述接口和部分行为的概念，请使用抽象类。