Checklist: Protocol
This checklist helps make sure that a Protocol is specified correctly
Relationships
Main Description


Check Items
The protocol class name is unique
The protocol is used in at least one collaboration
The protocol's brief description captures the purpose of the protocol and briefly summarizes the role it plays in the system
The protocol represents a single set of cohesive responsibilities
The signals in the protocol are all directly related to fulfilling the protocol's role in the system
They are not simply the signals used for communication between two capsules
The signals have been chosen in the most general way possible while still retaining clarity
 For example, in the case where several 'Out' signals all require acknowledgement, a single 'Ack' signal has been used as the response.
The protocol reflects a singular purpose in the system
 Where a protocol has a mixture of concerns (e.g. call processing and administration signals), it has been divided into several independent protocol classes.
Protocols have been defined in terms of what the use wants or needs to know instead of what the provider knows
The guideline which determine the side of the interface to be conjugated is applied consistently.
Asymmetric protocols are defined from the client (user) perspective to reduce the need to conjugate interfaces.
Asymmetric protocol classes are named to clearly indicate their directionality
A good example for name is 'ClientResourceInterface'