[UML Forum] Accessing actor operations on a sequence diagram?

[Ken]

Hi. I am using a UML tool to draw a sequence diagram. I want to show
that a class from my system under development (SuD) is using a service
provided by an actor. In the past, I would do this by adding a port
to the actor, then adding a provided interface to that port. After
doing that, on a sequence diagram, I could draw a message arrow to the
actor and call operations on that interface.

However, I recently started using a new UML tool. This tool does not
allow me to add a port to an actor. Also, while it lets me draw a
realization arrow from an actor to an interface, I cannot access the
interface's operations when I put the actor on a sequence diagram.

The tool vendors told me that according to the UML spec, an actor may
not implement operations from a realized interface, and thus a class
may not call operations directly from an actor on a sequence diagram.
Instead, I'd need to type a message name on the message arrow--but
that message name would not be reusable across sequence diagrams,
i.e., it would only exist on the one message on that one sequence
diagram. This means that if I'd need to change the message name, I'd
need to change it manually across all sequence diagrams that use it.

So my question is this: Are they correct in their statement? If they
are, how does the UML 2.0 spec provide for defining provided
interfaces on an actor in such a way that the interfaces can be
accessed by classes on many sequence diagrams?

Thanks for any help!

Ken

--
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To post to this group, send email to umlf...@googlegroups.com.
To unsubscribe from this group, send email to umlforum+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/umlforum?hl=en.

[timot...@freenet.de]

HI Ken,

Actors are specializations of BehavioredClassifier which is again a specialization of Classifier. So at first, the vendor is correct. I'm indifferent whether Actors are intended to be called by lifeline... obviously not, because the are not allowed to own operations. Even the UML spec doesn't mention anything about using actors outside of the Use Case diagram. However, since they are classifier, it is possible to include them into interactions. I have never seen interactions, where an Actor is called, but interactions where they are triggering other lifelines solely.

What i can suggest is:
1. Create your interface with the specific operations, the actor should provide.
2. Let the actor realize the interface
3. Add a property (ConnectableElement) to the classifier owning the interaction (in most tools a Collaboration) and type it with the interface your actor is implementing.
4. Connect the actor and the lifeline, representing the actor, with a dependency that fits best for you. I would recommend <<derive>>, pointing from the lifeline to the actor.

Any other discussion are welcome. It is a quite interesting topic, i think

Timothy

[H. S. Lahman]

Responding to Ken...

> So my question is this: Are they correct in their statement? If they
> are, how does the UML 2.0 spec provide for defining provided
> interfaces on an actor in such a way that the interfaces can be
> accessed by classes on many sequence diagrams?
>

The tool vendor is right. In fact, you really should not be able to put
and Actor in any diagrams except a Use Case Diagram. They were
introduced solely for the UCD and the UCD is only there to provide
traceablility between requirements (use cases) and model elements (OOA/D
solutions). Unfortunately there is no convenient way in the UML meta
model to restrict classifiers to a specific diagram. Typically the MDA
profiles for specific design methodologies will not let you put them
anywhere except a UCD.

To do what you want to do you need to define the services provided
externally by the actor in both a Deployment Diagram and a Component or
Class Diagram. The DP describes that the service is deployed separately
from the rest of the application. The CDs describe how the rest of the
software is logically related to it at the subsystem (Component Diagram)
and/or object (Class Diagram) level.

Typically external software is represented in a Class Diagram with a
surrogate object that essentially just represents an interface to it.
You can then describe the message flows between your application's
objects and the surrogate object in an Interaction Diagram. IOW, the
surrogate object is a kind of placeholder proxy that allows you to
describe interactions normally. At the OOP level the surrogate object
will be mapped into "bridge" infrastructure between subsystems.

--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html

[Ken]

Hi. I can see how this would work, but it seems like such an indirect
way to show the dynamic usage of an actor's contract, i.e., the usage
of the actor's interfaces required and provided by the System Under
Development. However, I suppose that's just how the UML Spec
crumbles. :)

Maybe UML 3.0 would consider allowing a port on an actor and an
actor's interfaces to be accessed through the actor on a sequence
diagram. Any thoughts as to why that would be a bad thing?

Thanks,

Ken

Thanks for the responses!

Ken

> H.lah...@verizon.net

[H. S. Lahman]

Responding to Ken...

> Hi. I can see how this would work, but it seems like such an indirect
> way to show the dynamic usage of an actor's contract, i.e., the usage
> of the actor's interfaces required and provided by the System Under
> Development. However, I suppose that's just how the UML Spec
> crumbles. :)
>

That's kind of the corner one gets painted into when the UML meta model
cannot limit model elements to particular diagrams. Speaking for the
translation MDA profiles, you would never be able to use an Actor model
element anywhere but a UCD and you would not be allowed to associate
interfaces with it there. B-)

Note that the original intent of actors was to abstract a /human/ user
of the application and humans don't provide software components. We have
extended that notion to include programmatic interactions with external
software "users" because it is a convenient metaphor. However,
conceptually in OOA/D there is a clear line in the sand between Us vs.
Them, Internal vs. External, Designed vs. Realized, or any other way one
wants to express Inside vs. Outside. Anything Outside the software in
hand that is being modeled lives in another world that the designer
doesn't care about. The only manifestation of the denizens of that other
world are incoming and outgoing messages.

That provides complete logical decoupling so that one can design the
software Inside without knowing who is Outside, what they are doing
Outside, and how they are organized Outside. The only semantics they
need to share is the semantics of {message ID, data packet}, and even
that they can interpret in terms of their local context. So when we
extend the notion of 'actor' to programmatic interactions, the software
Inside should be unaware of that and should treat the interactions just
like any other messages. In addition, the software Inside should be
completely ignorant of the sources of incoming messages from Outside or
the routing of outgoing messages to the Outside.

In fact, in OOA/D we provide specific models for subsystem interfaces so
that we can isolate and encapsulate the mechanics of message passing so
that the designer of a subsystem is not distracted by implementation
issues around who is sending/receiving messages, distributed
infrastructures, and whatnot. The notion of a surrogate object is
essentially a design pattern for providing that decoupling. That also
ensures a standardized approach that works equally well for GUIs, web
UIs, DBMS access, other applications, hardware, or even subsystems
within the same application. So I would argue it is actually a very
elegant approach to large-scale logical decoupling that greatly enhances
maintainability. IOW, ...

> Maybe UML 3.0 would consider allowing a port on an actor and an
> actor's interfaces to be accessed through the actor on a sequence
> diagram. Any thoughts as to why that would be a bad thing?
>

... it doesn't need to be fixed. B-) Leave the Actors in the UCD and
treat all software outside the subsystem in hand as Outside. Then all
one needs to provide is identity mapping and message passing mechanisms
in the subsystem bridge* implementation. [Note that one of the important
tasks of the Systems Engineer is to define communications between
large-scale modules so that they can be developed independently. So in
OOA/D that task belongs to a different trade union than the development
of the participating modules. So when mixing crafts, standardization
tends to be a Very Good Thing.]

* 'Bridge' has been in the translation lexicon for nearly three decades
and all the translation tools support it. But UML has not caught up yet
and still doesn't provide a means to specify communication
infrastructure /between/ subsystems. A bridge simply identifies a
communication path between large-scale entities (hardware and software
subsystems or applications). That allows one to specify the resolution
of syntactic mismatches within bridge implementations without cluttering
participating subsystem implementations. That is useful because one can
usually provide multiple syntaxes (interfaces) to describe any given
subject matter semantics. So when one attempts large-scale reuse one
tends to encounter clients in new reuse situations that want to use a
different message syntax than the service provides. [There is a posting
in the Application Partitioning category of my blog that describes one
such 2-way model for subsystems interfaces.]

--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman

H.la...@verizon.net

[Ken]

Well, here's what I did. In my model's "context" package where I used
to just keep my actors and a subsystem artifact for the SuD, I now
have a package for each actor. This package contains an actor to use
on use case diagrams and a subsystem artifact to represent the actor
on sequence and collaboration diagrams. I then used a UML profile to
create an "actor" stereotype that can be applied to ports on these
external subsystems.

This now allows me to leverage the semantics of "actor" with a place
to hang its ports and interfaces, so they are accessible on the
interaction diagrams. And it all is UML 2.0 compliant.

Thanks for all your input!

[RJB]

So, we have the user's view of themself and other actors plus the
systems view of the user. I'd like to know how this works out in the
long term.... Could you let us know what happens???

RJBotting
"The wise architect designs the pathways on a campus after it has
snowed and
they can see where people actually want to walk."

[Ken]

We don't really have the user's (actor's) view of themself. I only
show the actors in the context of the SuD and its components, i.e., I
only show the actor's interfaces that are required by the SuD and the
actor's required interfaces provided by the SuD. I do not show any
other actor details or interfaces. In fact, the description of the
actor is in terms of its relationship with the SuD.

Doing this provides a useful view of the SuD and the actors it
requires or serves, which really provides the context for the SuD's
existence. If I only showed the actors as interfaces on sequence
diagrams, it would really render the use case diagrams useless, since
I'd see actors but I'd not see how they are being used.

Beyond showing these actor interfaces, I treat the actors as black
boxes.

I've been doing this for about 4 years where I work on developing
complex sets of interacting subsystems. We organize our models (which
are at the subsystem level) by collaborations, ala RUP. It has worked
out well so far.

- Ken


We have the SuD's view of the user's contract, namely the services the
actor provides which the SuD needs and the services required that the
SuD provides.

Note that I do not show any interactions between actors.

[Jim Logan]

Ken,

Have you looked at SoaML?

-Jim

Sent from my iPhone