Some software component modeling languages have adopted a similar convention
for the services provided and required by various components. In contrast with the ?¬?rst
kind of ports, which are de?¬?ned as part of the modeling language, these component
interface ports are added by the modeler to each object as he sees ?¬?t. Since the ports are
then part of the model, not the metamodel, they cannot be constrained in the same way
by rules. Similarly, all such ports have the same semantics, reducing the ability to
generate useful code from them.
Modeling languages generally fall into two categories: those that primarily use role
and relationship types to express rules, and those that use ports. Where ports are used,
there is often no semantic need for different role types: distinguishing between ???To???
and ???From??? is not done by role type, but by ???In??? and ???Out??? ports. Ports and roles can
WHAT IS NEEDED IN A DSM ENVIRONMENT 371
still usefully be combined for notational convenience: a separate ???To??? role type to
show an arrowhead when connecting to an ???In??? port, or constraining a ???From??? role
type to always leave from the right or bottom edge of a symbol.
Language for Arbitrary Constraints The rules for connecting objects via
relationships, roles and ports are a vital part of a modeling language.
Pages:
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711