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.
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.
Don't do that. If PaymentInformationPartnerA extends PaymentInformation then for all uses of PaymentInformation you can use PaymentInformationPartnerA, whereas you are saying that for some uses ( assigning a value to ccType of "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.
Related
I have a UML class Student that has an attribute id. I want to write a query in OCL to find a particular Student by only knowing its id. Should I use allInstances()? Or derive? I'm not very familiar with OCL.
Usually OCL is used to express some constraints on an UML model, in relation to a given class instance (context or self) and you’ll start navigating from a specific instance.
But OCL was developed as a formal specification language that can be used to specify more than only constraints, and in particular queries as explained in section 7.1. of the OCL specifications.
If you want to express something regarding all the possible instances of a class MyClass, you would then start your clause with:
MyClass.allInstances()
Wich is a set containing all the instances of the given class. Typically, you would then operate on this set to further specify some model features.
For example, to express uniqueness of an id, you would write a Boolean clause on this set (based on example of section 7.5.10 of the OCL specs)
MyClass.allInstances()->forAll(e1, e2 | e1 <> e2 implies e1.id <> e2.id)
One of the operation you can perform on such set is to create a subset by selecting elements that match a certain condition, and this should answer your question:
MyClass.allInstances()->select(c|c.id='...')
Additional thoughts:
OCL is an abstract language. Nothing is said on how this expression will be implemented. It could be a large inefficient iteration over an in-memory collection, or a very effective SQL query. OCL will help you to define what the result should be, but not how to really get it. So performance should not be your concern at this level of abstraction.
Now, you didn’t tell the purpose of your OCL query. If it is to explain how database queries will be performed, you could see some advantages in separation of concerns: identify the relevant classes and reusable queries and enrich your model using the repository pattern: a repository is a (singleton) class MyClassRepository that acts as a container of all objects of a given MyClass in the database. You would then define operation for manipulating and querying the database. Typically, you’ll have a couple of getXxxx() operation like getById() that return one or a set of several instances. First it will make explicit what is to be implemented as a database functionality, second the new operations can be used to simplify some OCL expressions.
Yes. allInstances() is the easy solution, but potentially the least efficient and not necessarily flexible.
If your application and constraints (for one School) are expanded to multiple schools you may realize that actually you wanted the Student at a particular School, so it is often better to go to the logical context and invoke a method on the School to return a given Student. Perhaps this is what you meant by 'derive'. The implementation of School.students->at(id) might well use a Map giving multiple gains, through not searching the whole model for every access and through having a fast access to what you have already got.
I'm struggling at understanding UML component diagram.
I've just been through the "assembly connectors" and here's what I (think I) understood:
the circle represents an interface, which I understand as a set of functions that a component can offer to the others.
the half-circle... well, don't know how to call it, but it says something like "there's some functions I need in order to operate correctly". In the image, I guess that an order must have access to functions that return details of the Customer (e.g: methods GetName(), GetAddress(), etc.), that's why it has the assembly connection with the Customer Details interface, provided by Customer.
My question is: why is there a dependency relationship arrow from the interface which Account provides (AccountDetails) and the interface which Order requires (Payment)?
The link of this image doesn't explain it.
The assembly connector (two shown on top) is a kind of provisional concept. You know that there should be an interface used instead, but have not yet made up the details. This is a connector which looks like socket/lollipop. But it's a connector.
The separate lollipop/socket are concrete interface uses. These are real elements. The interface itself is not actually shown (you will have a separate diagram showing the details). But to make clear that the depending interface is related to the providing one you draw a dependency.
Simply spoken, the above is something in the middle of a design phase. Finally all assemlies should be replaced by provided/required interfaces.
I m trying to build a rest easy service with hibernate. Is it Good to have Hibernate and Jaxb be annotation both on the same class. OR there should be two different classes one for hibernate data object with annotation and another similar class for rest request and response with jaxb annotation.
The question is, basically if you need extra transfer objects next to your entities.
If you don't, the structure of your tranfer data (JSON, XML, whatever) will be more or less dictated of how your entities are structured. You can achieve a lot with annotations but you'll still be somewhat bound. As a consequence of this, changes in the entities may need to be propagated to your outer interfaces. Basically, if you change your entities and/or your database schema, you may also need to change the structure of the JSON returned by your REST interface.
Having separate DTOs is safer in cases when you need to provide stability of your interfaces. The downside is that you'll need mapping code to convert between DTOs and entities.
From my experience, you can get away with just entities most of the time.
What is the best way to represent a "mixin" using UML?
As documented in this article:
In object-oriented programming languages, a mixin refers to a defined
amount of functionality which can be added to a class. An important
aspect of this is that it makes it possible to concentrate more on the
properties of a particular behaviour than on the inheritance
structures during development.
I will give more details about my particular use case.
I have a collection of classes that model different types of objects. Because all of them can be stored on a storage, I want to use a mixin to implement all the functionality related to "being stored".
Of course, I can use abstract classes but I do not like it because these classes should be part of a different hierarchy of classes and the fact that they can be stored is only a secondary property.
Another option can be to use composition and add the "storage node" as a field of this classes. I do not like this option either for the same reason: I do not want to create any dependency between the classes and the storage.
I have already implemented the solution in Java using a mixin based on dynamic proxies and I would like to document the solution with a clear UML class diagram. Is there a standard way to represent this mixin?
I am also wondering whether it is a good idea to model also how the mixin has been implemented (using proxies) or it is better to use a more abstract representation.
Thanks
Actually there are many ways to model this in UML:
One approach could be to stereotype the operations and properties with <<mixin>> or the like and then use tagged values to describe where you got them from.
Another (I'd prefer) is to actually use a <<mixin>> stereotyped Generalization and attach a note to that telling which operations/properties should be mixed. That would give the implementer a guide to just "lean implementation of the general class".
Eventually you could create <<mixin>> sub-classes with subsets of the ops/props you want to mix in the final class and then Generalize from those.
Probably one could come up with more solutions. Use an approach which suits you best. There is not generic mixin pattern in UML (to my knowledge).
So Meta Programming -- the idea that you can modify classes/objects at runtime, injecting new methods and properties. I know its good for framework development; been working with Grails, and that framework adds a bunch of methods to your classes at runtime. You have a name property on a User object, and bamm, you get a findByName method injected at runtime.
Has my description completely described the concept?
What else is it good for (specific examples) other than framework development?
To me, meta-programming is "a program that writes programs".
Meta-programming is especially good for reuse, because it supports generalization: you can define a family of concepts that belong to a particular pattern. Then, through variability you can apply that concept in similar, but different scenarios.
The simplest example is Java's getters and setters as mentioned by #Sjoerd:
Both getter and setter follow a well-defined pattern: A getter returns a class member, and a setter sets a class member's value. Usually you build what it's called a template to allow application and reuse of that particular pattern. How a template works depends on the meta-programming/code generation approach being used.
If you want a getter or setter to behave in a slightly different way, you may add some parameters to your template. This is variability. For instance, if you want to add additional processing code when getting/setting, you may add a block of code as a variability parameter. Mixing custom code and generated code can be tricky. ABSE is currently the only MDSD approach that I know that natively supports custom code directly as a template parameter.
Meta programming is not only adding methods at runtime, it can also be automatically creating code at compile time. I.e. code generating code.
Web services (i.e. the methods are defined in the WSDL, and you want to use them as if they were real methods on an object)
Avoiding boilerplate code. For example, in Java you should use getters and setters, but these can be made automatically for most properties.