You could simply use the interface class. Whatever class contains the logic for creating an instance of A will contain two arrows to the time-line of the interface class. The first line will indicate the instantiation and the second line will indicate the call to method M().
If it is important to detail both sequences of when the condition is true and when it is false, you would create two sequence diagrams (one for each case). In these diagrams you would use the actual concrete class instead of the interface class. You could add a stereotype to the class indicating that it is an instance of A with <<A>> (a nice touch). Note, you have to determine whether this detail is important enough to include on your diagrams. Personally, I don't think so.
Also, the way you are creating the objects should be looked at again. In your example, you have a significant syntax-level dependency upon the class name. Very Bad! I suggest you read up on the Creational object-oriented design patterns and rethink how you create objects.
Good luck! [ July 08, 2008: Message edited by: James Clark ]
1. This piece of code is too trivial. It does not have to appear in your sequential diagram. 2. The creation part shall be in an AFactory class. And you can just show A and AFactory in your diagram, as no matter what kind of A it is, you use it in the same way anyway. 3. If you really want to show the branch logic, use UML2's "alt" frame.
Hi All, Thanks a lot for your replies. I agree, I should be using a Factory instead of that code. But it again brings to same point. There will be an interface AbstractFactory which will be implemented by ConcreteFactory. Now my client class will have something like
mmm... why are you so interested to show the interface classes in your sequence diagram? your seq. diagram should show the interaction between objects of certain classes, it doesn't need to reflect your class diagram on it.
So, you will not add that complexity to your seq. diagram. the developer will not look for inheritance in this diagram, he will look at the class diagram to create the classes, and then use the seq. to develop the methods. [ July 10, 2008: Message edited by: Juan Pablo Crossley ]