在面向对象模型中限制字符串的最佳方法是什么？
我需要选择一种建模方法来记录现有 Web 服务集合的扩展。该方法/工具需要由技术业务分析师使用。现有的API是在XML Schema中定义的。 XML 模式运行良好，但有一个例外。以 PaymentInformation 类为例。例如，一个合作伙伴可能会接受 Visa 和 Mastercard。另一个也是除美国运通之外。我们希望能够扩展 PartnerA 和 PartnerB 的 PaymentInformation。
class PaymentInformation
method // CASH,CC
ccNumber
ccType // MC,V,AMEX
class PaymentInformationPartnerA
method // CASH,CC,PAYPAL
ccNumber
ccType // MC, V
XML 模式的问题在于，对类应用限制需要重新定义整个类型。这似乎是一场维护噩梦。 UML 似乎不支持受限字符串（模式、长度等）。您为此推荐什么工具/方法？我们对 Eclipse IDE 有偏好，但不是必需的。
I need to select a modeling method for documenting extensions to an existing collection of web services. The method/tool needs to be used by tech business analysts. The existing API is defined in XML Schema. XML Schema work well with the one exception. Take a PaymentInformation class as an example. One partner might accept Visa and Mastercard as an example. Another also excepts Amex. We want to be able to extend PaymentInformation for PartnerA and PartnerB.
class PaymentInformation
method // CASH,CC
ccNumber
ccType // MC,V,AMEX
class PaymentInformationPartnerA
method // CASH,CC,PAYPAL
ccNumber
ccType // MC, V
The problem with XML Schema is that to apply a restriction to a class requires redefining the whole type. This seems like a maintenance nightmare. UML doesn't seem to support restricted strings (patterns, length, etc). What tool/method do you recommend for this? We have a preference, but not a requirement for Eclipse IDE.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以在您的类上添加 UML 约束或条件。这要么是图形注释，要么是直接在 UML 元模型上编码的信息手。
UML 模型已经是 XMI 2.1，因此类似于 XML，但使用特定的规则。
You can add an UML constraint or a condition on your class. This is either a graphical note or directly an information hand coded on the UML metamodel.
The UML model is already an XMI 2.1 therefore like a XML but using specific rules.
不要那样做。如果
PaymentInformationPartnerA扩展了PaymentInformation，那么对于PaymentInformation的所有使用，您都可以使用PaymentInformationPartnerA，而您是说对于某些使用（将值分配给"AMEX"的ccType）它不是协变的。您最好将约束作为端点接收消息的先决条件，而不是作为消息类型本身的约束。
Don't do that. If
PaymentInformationPartnerAextendsPaymentInformationthen for all uses ofPaymentInformationyou can usePaymentInformationPartnerA, whereas you are saying that for some uses ( assigning a value toccTypeof"AMEX") it is not covariant.You're probably better off putting the constraint as a pre-condition of the endpoint receiving the message rather than as a constraint on the message type itself.