The diagram shows sample Class diagram and usage of objects of those classes in Sequence diagram.
In the above diagram instance myCar can be referred either by reference of ShowroomItem or reference of interface Vehicle. Accordingly the clients Driver/ SalesEngineer will get functionality access.
I agree that in implementation stage (e.g. Java), type identification is not required here and we will treat myCar as instance of base type (either interface) used itself.
But in sequence diagram, (for clarity) I am unable to indicate that the reference for myCar for Driver should be of Vehicle and for SalesEngineer should be of ShowroomItem.
I searched in UML 2.0 books, I did not get suitable notation. As per current understanding, I can show it either as "myCar : Vehicle" or "myCar : ShowroomItem", but that does not indicate that its Object of Car referred as Interface. This shortcomming does not enforce that playMusic can not work when referred as Vehcile.
Is there any notation to show this kind of detail?
As I am not satisfied with any answer provided, I am trying to add following to make question more clear, address some objections raised in the answers and proposing kind of solution for experts to review.
Looking at the comments, I feel either people did not get the core question, or I failed to highlight the core issue. First let me demonstrate code does not break. following code allows SalesEngineer to access Abstraction with sell() and buy() functionality and Driver to access Abstraction with only start() and stop() functionality [designed that way]. This is a strongest feature of interfaces to publish different abstractions to different clients. Java Collections use same multiple base types namely Object and Comparable in TreeSet, one for equals() and another for compare() on entities.
package com.se.stackoverflow;
interface Vehicle {
abstract void start();
abstract void stop();
}
interface ShowroomItem {
abstract void buy();
abstract void sell();
}
class Car implements ShowroomItem, Vehicle {
// **Car IS-A Vehicle and ShowroomItem BY-DEFINITION**
// **and as per SOLID principle interface segregation**
public void start() { System.out.println("Started");}
public void stop() { System.out.println("Stopped");}
public void sell() { System.out.println("Sold");}
public void buy() { System.out.println("Baught");}
}
class SalesEngineer {
private ShowroomItem item = null;
public SalesEngineer(ShowroomItem item) { this.item = item;}
public void doTransaction() {item.buy(); item.sell();}
}
class Driver {
private Vehicle veh = null;
public Driver(Vehicle veh) {this.veh = veh;}
public boolean testDrive() {veh.start(); veh.stop(); return true;}
}
public class ShowroomOwner {
public void makeDeal(Car carForDeal) {
Driver driver = new Driver(carForDeal);
SalesEngineer engineer = new SalesEngineer(carForDeal);
if (driver.testDrive()) {
engineer.doTransaction();
}
}
public static void main(String[] args) {
// simulates client as ShowroomOwner to save space
new ShowroomOwner().makeDeal(new Car());
}
}
After referring "UML 2 and Unified Process" by Jim Arlow, I found we can show changing states over life line in sequence diagrams. I feel similar notation we can use to show changing types object [i havnt seen this documented in UML anywhere but its my suggestion to UML group].
e.g. here myCar is Object of its class Car (class of object can never be changed) but its reference type varies as per the left side like ShowroomItem or Vehicle.
May be following sequence diagram can show it. [Example classes are just indicative to highlight auto type casting effects]
